Greetings
I have run up ldbc...
http://ldbc.sourceforge.net/
with hsqldb and postgres. MySQL next.
There are significant changes required to allow ldbc
to be used.
Minor SQL syntax changes and table changes...
ldbc does not support cascading yet so I chopped that out.
Modified the delete routines to delete the right stuff.
I first fired it up with hsqldb and it worked fine after
some sql changes to comply with ldbc and then changed over
to postgres and run across an overflow error...
The uniqueId for XB_ENTRIES dataId failed the
range checks in ldbc >= 10^18.
I will try and figure out why it would work with postgres
using its jdbc and not with ldbc.
Anyway I think that ldbc looks very promising.
Apart from the changes needed to make xmlBlaster comply
it integrates seemlessly...
I.E. Change the jdbc list to only have org.ldbc.jdbc.jdbcDriver
(ldbc loads the real jdbc itself), modify the db url to read
jdbc:ldbc:hsqldb:etc and set the mappings up...
url=jdbc:ldbc:postgresql://localhost/test[ldbc.trace=detailed],
url=jdbc:ldbc:hsqldb:${user.home}.....[ldbc.trace=detailed],
ldbc.trace = off, on or detailed for debugging.
JdbcDriver.mapping[HSQLDatabaseEngine]=string=VARCHAR(128),longint=BIGINT,int=INTEGER,blob=BINARY,boolean=CHAR,blobVarName=ablob
ldbc does not accept VARCHAR without a range specifier (128).
blobVarName mapping required. There are alternative mappings
as ldbc maps a whole lot to its types which then get mapped
to the db's types.
Like mySQL, ldbc does not like the reserved word blob being
used as a field name.
If the overflow problem can be straightened out without having
to change the size of it when generated then it could be possible
to supply an ldbcManagerCommonTable plugin.
This would obviously obsolete the old way and the recent stuff with
mySQL and open up the number of db's supported to the list ldbc supports.
A bit of background on why the uniqueId is so big would be nice?
On my system it generates 19 digits I think.