Re: [xmlblaster] Ldbc

[Michele Laghi <laghi at swissinfo.org>]

Hi Peter,
I have looked at the code and in fact it should be possible to implement 
all in one single common code by adding two more configuration parameters.

Paring the mapping should be possible after some code modification (the 
',' inside a mapping should not break in future)

Before I start however I want to make sure the current code works. I 
tested the ldbc with postgres and there is one only error in the 
testsuite. It fails when making the request in peekBySamePriority when 
12 entries in the queue and 4 entries expected to be peeked. The statement:

"SELECT * from TEST_ENTRIES where 
queueName='callback_QueuePluginpeekMsg' and nodeId='xmlBlaster' and 
prio=(select max(prio) from TEST_ENTRIES where 
queueName='callback_QueuePluginpeekMsg' AND nodeId='xmlBlaster')  ORDER 
BY dataId ASC"

with the error

[Nov 18, 2003 10:05:08 PM TRACE LdbcPreparedQuery] Constructor. 
SQLException: 37000

Any idea about the cryptic 37000 ?


About the tests: I think it is not necessary to write new tests: the 
criteria that the old tests should pass should be sufficient.

Saluti
Michele


Marcel Ruff wrote:
> Peter Bennett wrote:
>
> > Marcel Ruff wrote:
> >
> > > Peter Bennett wrote:
> > >
> > > > Greetings
> > > >
> > > > Have uploaded the Ldbc stuff...
> > > >
> > > > I ran a few more tests yesterday and today...
> > > > I think I have a problem with one topic test.
> > > > testVolatile...
> > > >
> > > > 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 ...
>
> regards,
>
> Marcel
>
> > > > ldbc does not support cascade delete so I added some code and am not 
> > > > sure I am deleting enough...
> > > >
> > > > Regards


--
Michele Laghi
mailto:laghi at swissinfo.org
tel. +46 8 7492952 / mob. +46 70 4103964
http://eclettic.tripod.com
http://www.xmlBlaster.org