Bug #5187
closed
Incorrect result from filterExpression where the predicate compares boolean against untypedAtomic
Applies to branch:
10, 11, 9.9, trunk
Fix Committed on Branch:
10, trunk
Fixed in Maintenance Release:
- Description updated (diff)
- Status changed from New to In Progress
- Priority changed from Low to Normal
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.
Added qt3 test cases in prod-Predicate, predicates-33 to -35. Test -35 involves comparison with multiple types and elimination of duplicates.
- 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
- 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.
- % 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.
Leaving bug as resolved until fix applied to the Saxon 10 maintenance release.
- 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.
- Fixed in Maintenance Release 11.1 added
Please register to edit this issue
Also available in: Atom
PDF