[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xmlblaster] Ldbc

Peter Bennett wrote:
Marcel Ruff wrote:

Peter Bennett wrote:


Have uploaded the Ldbc stuff...

I ran a few more tests yesterday and today...
I think I have a problem with one topic test.

I have no doubt it will need some more work...

I already need to add a couple of notes to the ldbc requirement...

(1) JDK 1.4 only.

Hu, does this mean that xmlBlaster is not compiling / running with JDK 1.3 / 1.2 anymore?

No... Just the ldbc driver is compiled under 1.4. I just read the ldbc howto again and I missed something... It can be compiled under JDK1.3. I better redo the jar under 1.3. Should I upload a set of docs for ldbc?

Probably its better to add those links to the ldbc requirement.

(2) No Oracle support in ldbc.jar

Well, we still have the native Oracle support.

Ldbc does support Oracle... I don't however. Its scary.
From the ldbc howto... The Oracle JDBC driver needs to be in the build class path. I don't have a recent Oracle jdbc driver. Oracle users need to roll there own. Or somebody in the team download and build ldbc.

I have Oracle installed when i find time i'll look at it.

I think I need some Oracle files to compile Oracle support into the ldbc driver.

As you will see the code is virtually identical to the commontable plugin. The part I am not 100% sure of is the routine to delete stuff.

diff JdbcConnectionPool.java LdbcConnectionPool.java diff JdbcManagerCommonTable.java LdbcManagerCommonTable.java diff JdbcQueueCommonTablePlugin.java LdbcQueueCommonTablePlugin.java diff PreparedQuery.java LdbcPreparedQuery.java

It seems that only JdbcManagerCommonTable is replaced by LdbcManagerCommonTable,
only LdbcManagerCommonTable.java has two places with additional code.

We should somehow merge the files to avoid having duplicate code
and duplicate errors, probably having a common interface class
and having a factory to create with or without ldbc. Any idea?

Yes... I am sure Michele could look at the diffs and figure something out... But. Its just I hate getting him to make changes to support Ldbc/MySQL or whatever. I can put watches on the relevant files and do the diffs.

Yes/No :-) The problem is that everything should be automatically tested - otherwise one never knows if something broke or us outdated ...

One day we'll find a smart solution for this ;-)

There are many modules in xmlBlaster already (just think of the
python clients, JMX parts, Peter Antmans' jboss extensions ...) -
we definitely need automatic testcases for each piece and avoid
code duplication - how else shall we keep everything together?

We need to discuss if we really want to drop JDK 1.3 and 1.2 support.

 From the ldbc howto... Most likely JDK 1.2 also works.

I have no problems if it goes no further at present. It is just a go at abstraction. I will continue to work with it to see if I can improve and develop it. It is most certainly less strain on me if the development code is in the repository and it opens up the chance for others to look at it and test on there platforms if they are brave enough.

OK, thanks for all this, we look towards a bright ldbc future ...



ldbc does not support cascade delete so I added some code and am not sure I am deleting enough...