Apply node transforms to triple terms in expressions - #4173
Closed
jitsedesmet wants to merge 1 commit into
Closed
Conversation
ApplyTransformVisitor.visit(ExprTripleTerm) discarded the ExprTransform
instead of applying it, so no algebra transform could reach the variables
inside a triple term in an expression.
The visible effect is on sub-SELECT scope renaming. Variables of a
sub-SELECT that are not projected out are renamed ?x -> ?/x by
TransformScopeRename/Rename.renameVars so they cannot clash with usage
outside the sub-SELECT. That renaming did not reach inside a triple term,
leaving inconsistent algebra:
(project (?g ?tt)
(extend ((?tt (tripleterm ?x <urn:p> <urn:o>))) <- not renamed
(bgp (triple ?g <urn:hasX> ?/x)))) <- renamed
?x is unbound at evaluation time, so the BIND raises
VariableNotBoundException and extend leaves ?tt unbound. The query returns
the right number of rows with the triple term column silently missing and
no warning or error. For example:
SELECT * {
{ SELECT ?g ?tt { ?g :hasX ?x . BIND( <<( ?x :p :o )>> AS ?tt ) } }
?g :hasB ?b .
}
The renaming only happens when the sub-SELECT is joined with something at
the enclosing level, so the same BIND in a plain group, or a sub-SELECT
run on its own, was unaffected.
- ApplyTransformVisitor: apply the transform.
- ExprTransform: new default transform(ExprTripleTerm) returning the term
unchanged, so existing implementations are unaffected.
- ExprTripleTerm: apply(ExprTransform), as for ExprVar and NodeValue;
applyNodeTransform returns this when the node is unchanged.
- NodeTransformExpr, ExprTransformNodeElement: the NodeTransform bridges
pass the whole triple term node to the NodeTransform, which is the same
contract as triples in a BGP (NodeTransformLib.transform).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
ApplyTransformVisitor.visit(ExprTripleTerm) discarded the ExprTransform instead of applying it, so no algebra transform could reach the variables inside a triple term in an expression.
The visible effect is on sub-SELECT scope renaming. Variables of a sub-SELECT that are not projected out are renamed ?x -> ?/x by TransformScopeRename/Rename.renameVars so they cannot clash with usage outside the sub-SELECT. That renaming did not reach inside a triple term, leaving inconsistent algebra:
(project (?g ?tt)
(extend ((?tt (tripleterm ?x urn:p urn:o))) <- not renamed
(bgp (triple ?g urn:hasX ?/x)))) <- renamed
?x is unbound at evaluation time, so the BIND raises VariableNotBoundException and extend leaves ?tt unbound. The query returns the right number of rows with the triple term column silently missing and no warning or error. For example:
SELECT * {
{ SELECT ?g ?tt { ?g :hasX ?x . BIND( <<( ?x :p :o )>> AS ?tt ) } }
?g :hasB ?b .
}
The renaming only happens when the sub-SELECT is joined with something at the enclosing level, so the same BIND in a plain group, or a sub-SELECT run on its own, was unaffected.
GitHub issue resolved #
Pull request Description:
By submitting this pull request, I acknowledge that I am making a contribution to the Apache Software Foundation under the terms and conditions of the Contributor's Agreement.
See the Apache Jena "Contributing" guide.