Skip to content

Apply node transforms to triple terms in expressions - #4173

Closed
jitsedesmet wants to merge 1 commit into
apache:mainfrom
jitsedesmet:fix/triple-term-subselect-scope-rename
Closed

Apply node transforms to triple terms in expressions#4173
jitsedesmet wants to merge 1 commit into
apache:mainfrom
jitsedesmet:fix/triple-term-subselect-scope-rename

Conversation

@jitsedesmet

Copy link
Copy Markdown
Contributor

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).

GitHub issue resolved #

Pull request Description:


  • Tests are included.
  • Documentation change and updates are provided for the Apache Jena website
  • Commits have been squashed to remove intermediate development commit messages.
  • Key commit messages start with the issue number (GH-xxxx)

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.

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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant