[xwiki-users] Using XWiki in other databases than MySQL

[David Delbecq]

Ludovic Dubost a écrit :
>
> Yes,
>
> This is *very* useful. It's exactly what we need for databases we
> haven't tested XWiki on.
> So any field of more than 4096 should be converted to "text" in
> hibernate.cfg.xml (which should be compatible with mysql and the
> databases xwiki already works on).
> Oracle9Dialect should be use (does it mean forgeting support for
> Oracle8 ?)
> Text fields of more than 4096 cannot be handled using "like" so using
> the Lucene plugin is mandatory for Oracle
>
I don't know exactly, because, the "text" type is handled by hibernate,
this might just mean the oracle9dialect has to do complex things to
search in strings. but anyway; 'like', when used as an hibernate keyword
should be converted the good way to oracle query. As long as you stick
with hibernate level, it should be manageable :)
There is a good amount of doc on oracle website about the various data
types, and what is supported and not supported by TEXT and by CLOB

Also, oracle9dialect is an hibernate dialect that need oracle9 jdbc
driver, but this driver is able to discuss to oracle 8 databases (like
the oracle 10 driver can discuss to oracle 8,9 and 10)

note, i use TEXT, to represent the oracle datatype and text to represent
the hibernate type, fun is text is mapped to CLOB and string is mapped
to TEXT :p
Also, without promises, i thing i can digout the modified wiki i was
working on at the time we tested oracle
> Ludovic
>
> David Delbecq a écrit :
>> Reporting, out of my mind of months ago, for Oracle
>>
>> - First, oracle does assume an empty string same as null, this has 2
>> majors implications
>>    * The 'not null' String elements  can get nulled when stored on
>> database, triggering lots of hibernate exception when they are retrieved
>> again. The 'not null' should be removed from String and all string
>> getters in the bean should do something like return
>> (value==null?"":value). Only exception to this should be keys, but keys
>> can not be empty strings either. Oracle 10, i think is supposed to have
>> this problem fixed and nulls are no more same a empty strings. However,
>> oracle 9 here.
>>    * Another point, in sql, any boolean expression which implies a null
>> is systematically evaluated to 'false'. As a result, the SQL query
>> expression ":var1 not equal :var2 " is always evaluated to false if any
>> of :var1 or :var2 is an empty string on oracle. A workaround at that
>> time was to hunt expressions involving non key Strings and replace them
>> with more complex expression taking into account null cases
>> - Oracle is quite limited in the way it handles muliple lobs column in
>> the same table. The hibernate mapping of xwiki uses String of length >
>> 4096, this is converted to the type "TEXT" in oracle language. A TEXT
>> has nearly the same behaviour as a varchar in oracle, meaning it can be
>> used as a string in expression. However, there can be only one TEXT
>> field per row. When there were several String of length >4096 in
>> hibernate, they were all blindly converted to oracle TEXT type. The
>> database of course refused to create such tables. Another alternative is
>> clob (Character Large Object), you can have several on same row, however
>> they do not act like varchar (you can't use them like that in sql
>> expression). Hibernate oracle language does most of converting job (take
>> care there 2 hibernate languages, the one to go was oracle9Dialect) when
>> you chose the hibernate type 'text' instead of String.
>> - Then, there is no initial database for oracle. At the time i did all
>> my tests and patchups, i didn't know either there was a sample database
>> for mysql. Because i was lacking more development time, it has been less
>> time expensive for to drop our oracle patch ups everywhere and to switch
>> to a mysql environment, thought we mainly prefer to concentrate as much
>> as possible oracle here :)
>>
>>
>> Hope you find this information helpful
>>
>>
>> Ludovic Dubost a écrit :
>>  
>>> Hi,
>>>
>>> In order to possibly improve our database support in the future, I
>>> would be interested to discuss with any users that have ported XWiki
>>> to other databases than MySQL.
>>> We are especially interested by databases used by corporations like
>>> Oracle, Sybase, SQL Server.
>>>
>>> Would any of you that have ported/tried to port XWiki to another
>>> database tell us what has worked/not worked and what they have done.
>>> That would be great help.
>>>
>>> Since we now have the default database of XWiki as XML, we have the
>>> possibility to write a script to load this in any database.
>>> We just need to make sure that the core behavior of the storage engine
>>> is compatible with the target database.
>>>
>>> Thanks
>>> Ludovic
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>>
>>> -- 
>>> You receive this message as a subscriber of the
>>> xwiki-users at objectweb.org mailing list.
>>> To unsubscribe: mailto:xwiki-users-unsubscribe at objectweb.org
>>> For general help: mailto:sympa at objectweb.org?subject=help
>>> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>>>       
>>
>>
>>  
>> ------------------------------------------------------------------------
>>
>>
>> -- 
>> You receive this message as a subscriber of the
>> xwiki-users at objectweb.org mailing list.
>> To unsubscribe: mailto:xwiki-users-unsubscribe at objectweb.org
>> For general help: mailto:sympa at objectweb.org?subject=help
>> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>>   
>
>
> ------------------------------------------------------------------------
>
>
> --
> You receive this message as a subscriber of the xwiki-users at objectweb.org mailing list.
> To unsubscribe: mailto:xwiki-users-unsubscribe at objectweb.org
> For general help: mailto:sympa at objectweb.org?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>