Exist: Comparison bug with large xs:integer values

[median1st]

The FLWOR expression fails to order input tuples of xs:integer type and a large value. The output tuples are ordered by just a certain portion of the number digits taken from left.
Steps to reproduce - run this XQuery fragment:

let $data := (
310000000000920000300,
310000000000930001800,
310000000000930003900,
310000000000970000400,
310000000000930002800,
310000000000920000200,
310000000000930001700,
310000000000930004900,
310000000000930003800,
310000000000970000300
    )
for $i in $data
order by $i 
return $i

The result run on version 2.2:

310000000000920000300
310000000000920000200
310000000000930001800
310000000000930003900
310000000000930002800
310000000000930001700
310000000000930004900
310000000000930003800
310000000000970000400
310000000000970000300

When the query is changed to:

let $data := (
310000000000920000300,
310000000000930001800,
310000000000930003900,
310000000000970000400,
310000000000930002800,
310000000000920000200,
310000000000930001700,
310000000000930004900,
310000000000930003800,
310000000000970000300
    )
for $i in $data
(:  order by $i :)
order by $i div 10000000, $i mod 10000000
return $i

the result is correct:

310000000000920000200
310000000000920000300
310000000000930001700
310000000000930001800
310000000000930002800
310000000000930003800
310000000000930003900
310000000000930004900
310000000000970000300
310000000000970000400

[joewiz]

I get the same results for both queries on 3.0RC2 (latest from the develop branch).

[median1st]

That's great, but it does not solve my problem. I'm actually implementing a serious application using eXist, so I'm using the version 2.2 that has been tagged as "production stable". The 3.0RC2 is not yet considered stable for production.
The mentioned application should actually prove to the management that XMLDB is the right infrastructure and service for the data. If that's shown, the company would buy the support. But so far I'm stumbling over bugs in a stable release (this one is the less serious as it can be worked around).

[joewiz]

FYI, I'm just a user. I didn't claim to be offering to solve your problem - just adding context to advance your report. Specifically, I was saying that the problem _still affects_ 3.0RC2, the version currently in development. If you are thinking about commercial support from existsolutions.com, you should contact them via http://existsolutions.com/contact.xml, not via this issue tracker.

[median1st]

Ok, sorry for the harsh tone, but it was a bit confusing. Your comment could be easily interpreted as "when I run both queries from the issue on 3.0RC2, they give the same result", which would mean that the sorting is correct on the latest version (both queries order well).
Regarding the commercial support the situation is not yet mature - I have to prove to the management first that the "stable" release is able to run our pilot application. Then they would opt for contacting existsolutions for an offer of the comm. support.
So to conclude - my apologies for the misunderstanding and thanks for confirming the issue.

[joewiz]

You're right about the ambiguity in my response, sorry. I think you'll find 2.2 is stable, though as is to be expected, development hasn't ceased and has in many cases fixed bugs, added features, and improved performance since that release. Your plan sounds good. Good luck! And thanks for the bug report. Community participation is one of the things I like most about eXist.

[dizzzz]

The interesting thing is that if I check the variable type with util:get-sequence-type($data) or util:get-sequence-type($i), I actually see xs:integer.

[median1st]

@joewiz: 2.2 is definitively more stable than 3.0, that's right. Still I'm having a very serious issue with it, but I have no simple steps to reproduce it, so I'm a bit stuck in reporting it. Anyway, thanks for your feedback :-)
@dizzzz: The problem has been actually detected on a function that was declared to return xs:integer and I suspected the function first, but it turned out that the result was wrong even with static input. It's however interesting that the ordering seemingly honors about fifteen leftmost digits.

[joewiz]

This bug still affects 3.4.0. I think I've reduced it to this:

10000000000000001  eq 10000000000000002,
100000000000000001 eq 100000000000000002,
100000000000000010 eq 100000000000000020,
100000000000000100 eq 100000000000000200

The results should all be false(), but the actual results are:

false(),
true(),
true(),
false()

Saxon 7.5.0.15 gets this right, returning false() in all cases.

BaseX 8.6.5 matches eXist's buggy results.

[duncdrum]

@joewiz i think this might have been fixed, but could you update / submit a test pr, thx.

[line-o]

exist 5.3.0 is still affected
The test case can be boiled down to:

declare
  %test:assertFalse
function t:cmp-large-ints() {
  310000000000920000300 = 310000000000920000200
};