[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xmlblaster-devel] Bug hunting Analysis
nice to ear from you again.
Peter Bennett wrote:
I am sorry but making this addition on the xmlBlaster code is the wrong
place since it would be in contradiction with the idea of having the
extra layer of abstraction given by the ldbc driver. The correct place
where to hide this would be inside the ldbc code (alternatively in MySQL).
I think I have found the key to the problem...
I actually found it a while ago...
dataId is stored in a decimal(19,0) field...
MySQL stores decimal fields as char values.
SQL expresions are evaluated on the basis that the value is text.
This can be overridden by a simple add of 0.0 to type it as a floating
point value. Once typed as such the < less than comparison works.
(dataId + 0.0) < limitId
There is still one associated problem that I don't think I can fix...
Upon creation of the data base and subsequent check for persistant items
the sql statement fails... Probably because the dataId = null and adding
0.0 to null causes an exception. This problem only shows when the tables
do not exist... I.E Running the test suite without any existing tables
fails one test. Running the test suite when the tables exist works fine
I think the best thing to do here is to just note it in the requirements.
Can I go ahead and submit the modified code?
Peter Bennett wrote:
> Greetings Michele.
> I am still trying to figure out why I can't get through the
> peekWithLimitEntry test...
> Unmodified the code fails with mysql randomly.
> I can run the test suite over and over again and get results such as...
> 4 good runs in a row...
> Fail test 1 expected 3 got 5 or 4 sometimes.
> Fail test 3 expected 5 got 3 or sometimes 4.
> A good test or two and so on with seemingly random failures.
> If I put extra parenthasis/single quotes in to make the sql absolutly
> unambiguous I can get to a stable fail at test 3 with expected 5 got 3
> almost every time. Sometimes it will pass.
> These types of results lead me to the conclusion that the db or drivers
> have a problem. Maybe mysql is interpreting the decimal(19,0) field
> wrong. I have an idea it stores the number in a text format and this
> would explain the seemingly random failures...
> I.E 199999999999 would be greater than 200000000000 because lots of
> 9's added together as a text char compare is greater than lots of 0's.
> Maybe I will persue this avenue first... Seems everything else I have
> tried yeilds the same results.
> What started out to be the simple objective of running xmlBlaster with
> MySQL has turned into a nightmare...
> I am having a rest for a few days before it drives me insane.
> Merry Christmas to all.