Replies: 1 comment 2 replies
-
We fixed this at some point, not sure exactly when but it definitely shouldn't be a problem on the latest version. We also implemented a global test for this in https://github.com/eclipse/rdf4j/blob/main/core/queryalgebra/evaluation/src/main/java/org/eclipse/rdf4j/query/algebra/evaluation/optimizer/ParentReferenceChecker.java . |
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
This query parses as follows (and I've labeled a few nodes to facilitate discussion):
The parent of rhsX is rhs, which is what I'd expect, but the parent of lhsX is not lhs (and also is not rhs), but is a statement pattern that doesn't appear in the over parsed query.
This means that from an arbitrary node in the query, it's not possible to use
getParentNode()
to walk back up to the root of the parsed query. Any ideas what's going on here? I'm using RDF4j 3.7.4 (dictated by external factors, but if the behavior is different in later versions, that's still valuable information).Here's a JUnit that demonstrates the behavior:
As a workaround, since I'm actual using the visitor in real code (not manually extracting the bits as in the JUnit), I've just set the parent node on the children of statement patterns before calling
super.meet(node)
, and that seems to patch things up for me. Is there any danger in this approach?Beta Was this translation helpful? Give feedback.
All reactions