[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xmlblaster-devel] [Fwd: Re: [xmlblaster] Ldbc]
Michele Laghi wrote:
I moved this topic to the developer list since it is more appropriate.
I fixed the property parser to allow commas inside subproperties (for
the mapping). You just need to enclose the whole subpropery with double
Tomorrow I would add a flag "cascadeDelete=no" (yes per default) and
then we should have it all to be merged into JdbcQueueCommonTable,
making configuration, documentation fixes and testing simpler to be
done. (for the same reason we removed a while ago the original JdbcQueue).
Cascade Deleting: I have not looked at it.
Michele Laghi wrote:
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
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
"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.
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.
Hmmm strange... Postgres was the only db I was fully confident would
work... I will look into the error... They are not that easy to track
down. Thanks for the test.
As I said I am not sure I am erasing enough from the tables with the
replacement code to overcome no cascading delete in ldbc however that
may not explain the test results. Surely there are other tests that
erase and check.
As for your other suggestion about integrating the code... I have no
problem with this however we should wait for a while and get it stable
and working first.
There are one or two other areas that you have missed... Its the same
problem with () as the peek issue. They have been removed for ldbc.
LdbcManagerCommonTable addQueue Line number 618. Also table creation
code is different. Reference definition is slightly different in ldbc.
Code added in removeNode for delete. Can you verify this for me with
your superior knowledge of all things sql. There are three tables yet
there are only two delete statements. Am I deleting all that should be
given that with cascade functionality the db deletes the right records.