Conversation
|
Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have the users @Robin6939 on file. In order for us to review and merge your code, please contact the project maintainers to get yourself added. |
|
Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have the users @Robin6939 on file. In order for us to review and merge your code, please contact the project maintainers to get yourself added. |
|
Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have the users @Robin6939 on file. In order for us to review and merge your code, please contact the project maintainers to get yourself added. |
Description:
Issues:
Closes eXist-db/exist#4958
Closes eXist-db/exist#4810
What was wrong
The general comparisons engine only returns a node set for a comparison if the comparison is not empty.
If it is empty, it doesn’t return false, which is fine in most cases but can lead to issues like the ones I’ve fixed in this PR.
What I’ve done is: whenever an empty node set would be returned, I simply return false instead. This works in most cases, but not with the predicate engine. That’s because when general comparison is used, the context sequence indicates that the execution mode for the predicate engine must be set to "node" — i.e., it expects a node set instead of a boolean. I’ve made the necessary changes to handle that as well. I’m aware this might not be the ideal solution, but any alternative could would require significant changes across many functions.
Reference:
XPath 3.1 is explicit: a general comparison must return true or false, never a node sequence. See: 3.7.2 General comparison
Tests:
Added test cases for the same