Open joewiz opened 2 years ago
If the predicate does not (explicitly) depend on the context item we receive the expected return values.
doc("/db/test/test.xml")//w[exists(self::w)] ! preceding::pb
@line-o At first, I wondered if, in the same way that your original fix identified a problem with the abbreviated syntax //
that didn't affect the verbose equivalent /descendant-or-self::node()/
, could it be that this bug affects primarily the abbreviated syntax .
but doesn't not the verbose equivalent self::node()
? However, the following formulations exhibit the same error:
doc("/db/test/test.xml")//w[exists(self::node())]
doc("/db/test/test.xml")//w[exists(self::element())]
... though these formulations return the expected results:
doc("/db/test/test.xml")//w[exists(self::w)]
doc("/db/test/test.xml")//w[exists(self::element(w))]
Not sure if this helps shed any light on the issue...
Describe the bug
@line-o's PR https://github.com/eXist-db/exist/pull/4108 successfully fixed the cases provided in https://github.com/eXist-db/exist/issues/4085 - i.e., where the filter exercised was simply
[true()]
- but further testing has revealed additional cases that trigger the same bug. For example, if[true()]
is changed to one that selects the context node, such as[exists(.)]
, even a patched system will produce the same failures as described in the original issue.Here, too, eXist fails to locate some nodes along the
preceding
andfollowing
axes, when a document is stored in the database and when the predicate described has been applied to thefor
clause of a FLWOR expression or to the LHS of a simple map operator.Expected behavior
eXist should locate all matching nodes regardless of the XPath axis used and the expression used in a predicate that filter the result set.
To reproduce
The sample scenario and XQSuite test shown here is identical to the original XQSuite in https://github.com/eXist-db/exist/issues/4085, except the predicate is changed to one that selects the context node. With this change, even a system patched with https://github.com/eXist-db/exist/pull/4108 will produce errors identical to the original report.
As before, the bug arises only when the document stored in the database, and when a predicate is applied to the initial expression.
For example, given an XML document, stored in eXist as
/db/test/test.xml
:... a query that iterates over this document's
<w>
elements and applies a filter that selects the context node - even a meaningless[exists(.)]
- and then traverses thepreceding
axis to select the element's preceding<pb>
element, will trigger the bug. Here's an example query:w/@id
<pb id="pb1"/>
<pb id="pb1"/>
<pb id="pb1"/>
()
<pb id="pb1"/>
()
<pb id="pb2"/>
<pb id="pb2"/>
<pb id="pb2"/>
()
The XQSuite below performs this and variations on the test—showing the bug affects not just FLWOR expressions but simple map operator expressions too, and not just the
preceding
but also thefollowing
axis. The corresponding failing tests are:preceding-with-predicate-db-flwor
preceding-with-predicate-db-map
following-with-predicate-db-flwor
following-with-predicate-db-map
The results of this test are as follows:
Context (please always complete the following information):
Additional context
conf.xml
? none