Bug #5187
closedIncorrect result from filterExpression where the predicate compares boolean against untypedAtomic
100%
Description
See https://saxonica.plan.io/boards/2/topics/8414?r=8415
The expression takes the form /root/item[USE = SOUGHT]
where USE is a boolean expression, and SOUGHT evaluates to the untypedAtomic value "true".
Updated by Michael Kay almost 3 years ago
- Description updated (diff)
- Status changed from New to In Progress
- Priority changed from Low to Normal
Updated by Michael Kay almost 3 years ago
The index is being constructed correctly (a hash map from BooleanValue
to List<NodeInfo>
) but the lookup fails because no attempt is made to convert the untypedAtomic value to a boolean. There's plenty of logic dealing with the case where the USE value is untypedAtomic, but none for the case where the SOUGHT value is untypedAtomic. (Of course, if the USE value is a string, it all works cleanly.)
In a simple case like this where the USE values all have the same type and it's known statically, then this really shouldn't be a problem. It only gets difficult where there are multiple types.
While building the index we take care to maintain the property keyTypesPresent
, but the value seems to be unused when it comes to using the index. (There's no change here from 9.9 or 9.8 so it looks like a long-standing problem.)
Iterating over the types listed in keyTypesPresent
, and for each one, converting the sought value to the relevant type before doing a lookup in the index, appears to solve the problem. But we need to fast-path cases where this isn't necessary.
Updated by Michael Kay almost 3 years ago
Added qt3 test cases in prod-Predicate, predicates-33 to -35. Test -35 involves comparison with multiple types and elimination of duplicates.
Updated by Michael Kay almost 3 years ago
- Subject changed from Incorrect result from filterExpression where the predicate compares two booleans to Incorrect result from filterExpression where the predicate compares boolean against untypedAtomic
Updated by Michael Kay almost 3 years ago
- Status changed from In Progress to Resolved
- Applies to branch 10, 11, 9.9, trunk added
- Fix Committed on Branch 10, trunk added
On the 11.x branch, the first two tests pass without applying any fix to the code; this turns out to be because the optimiser generates a conversion of the untyped argument to the required type (this is done when converting the GeneralComparison to a ValueComparison if the types of both operands are known).
Never mind, predicates-35 fails so we'll rely on that one testing the patch.
Fixed in KeyIndex.getNodes() on the 10.x and 11.x branches.
Updated by O'Neil Delpratt almost 3 years ago
- % Done changed from 0 to 100
- Fixed in Maintenance Release 11.1 added
- Platforms .NET, Java added
Bug fix applied in the Saxon 11.1 release.
Updated by O'Neil Delpratt almost 3 years ago
Leaving bug as resolved until fix applied to the Saxon 10 maintenance release.
Updated by Debbie Lockett over 2 years ago
- Status changed from Resolved to Closed
- Fixed in Maintenance Release 10.7 added
- Fixed in Maintenance Release deleted (
11.1)
Bug fix applied in the Saxon 10.7 maintenance release.
Updated by Debbie Lockett over 2 years ago
- Fixed in Maintenance Release 11.1 added
Please register to edit this issue