Before, if the two compared literals had typedValues for which comparison was not supported by JavaScript, the first argument was always considered as lower than the second.
In this pull request, we compare first the kind of literals using buckets ("number", "string"...). If the two literals are in the same bucket, we proceed to the actual comparison.
If not, we compare the literals using the bucket identifier.
We do that instead of comparing directly the datatypes to avoid problems like "xsd:decimal" < "xsd:entity" < "xsd:integer" even if some decimals should be lower than integers.
This PR also simplifies the ordering tests to make sure all combinations of argument order and ascending/descending expectation are tested.
This PR removes the public Ordering.order that was completely unused.
The diffs are more readable if read commit by commit.
This is a first step to solve comunica/comunica#892
Coverage increased (+0.002%) to 89.507% when pulling 8e9e86c07e53f08623b2e02987dd81ea9599bb40 on Tpt:literal-order into 7c1180638154c72d3c3292e48d000ed9770796f0 on comunica:master.
Before, if the two compared literals had
typedValue
s for which comparison was not supported by JavaScript, the first argument was always considered as lower than the second.In this pull request, we compare first the kind of literals using buckets ("number", "string"...). If the two literals are in the same bucket, we proceed to the actual comparison. If not, we compare the literals using the bucket identifier. We do that instead of comparing directly the datatypes to avoid problems like
"xsd:decimal"
<"xsd:entity"
<"xsd:integer"
even if some decimals should be lower than integers.This PR also simplifies the ordering tests to make sure all combinations of argument order and ascending/descending expectation are tested.
This PR removes the public Ordering.order that was completely unused.
The diffs are more readable if read commit by commit.
This is a first step to solve comunica/comunica#892