[
https://issues.apache.org/jira/browse/JENA-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15831825#comment-15831825
]
ASF GitHub Bot commented on JENA-1275:
--------------------------------------
GitHub user afs opened a pull request:
https://github.com/apache/jena/pull/206
JENA-1275 : Trasnforming Expressions and VarExprLists.
This addresses JENA-1275 and also some related cases found during testing.
It also has some clear-up done in the areas touched.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/afs/jena JENA-1275_transform-expr
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/jena/pull/206.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #206
----
commit 843298cb5222c7ff6d28264fde4d3329bb1fd068
Author: Andy Seaborne <[email protected]>
Date: 2017-01-19T11:45:45Z
ApplyElementTransformVisitor: top level class; rename to avoid clash.
commit 0e8c032422dd3180a7b84e03a0dd6b9eccedf981
Author: Andy Seaborne <[email protected]>
Date: 2017-01-19T15:31:36Z
Remove initializer - it can block initialization.
Otherwise, initialization code can not assume Node is initialied
and so their internal constand Nodes can be null.
NodeFactory has an initializer call.
Var (which created Vars which are Nodes) has an initializer call.
commit 7212b6927e4f3c2f963f21c8f92b99787c659f9e
Author: Andy Seaborne <[email protected]>
Date: 2017-01-20T12:17:03Z
Rename old-style WalkerVisitors to OpWalkerVisitor* for clarity.
commit 9503d2b52b4df386b9c2fa123faf6a6d3d01c4f2
Author: Andy Seaborne <[email protected]>
Date: 2017-01-20T12:17:43Z
Visit the projection node.
commit f1c8131e2f2b3e70f3f54e04b6ad63753ba6d56a
Author: Andy Seaborne <[email protected]>
Date: 2017-01-20T13:43:42Z
Fix - put back call to walker.
commit b29d4fba5bae22ed40c324ca07a5a987bad8eb7b
Author: Andy Seaborne <[email protected]>
Date: 2017-01-20T13:44:04Z
Correct spelling
commit 09d22cf7b0cb16c78c65430aaa081c56e4302673
Author: Andy Seaborne <[email protected]>
Date: 2017-01-20T13:44:35Z
Add OpGroup.create, to be like other Ops.
commit 555410d9b51e93efbc4f844f03f447563df6963e
Author: Andy Seaborne <[email protected]>
Date: 2017-01-20T13:55:59Z
JENA-1275 : Process expressions, including 'exists', consistently.
----
> TransformScopeRename does the wrong thing with FILTER NOT EXISTS
> ----------------------------------------------------------------
>
> Key: JENA-1275
> URL: https://issues.apache.org/jira/browse/JENA-1275
> Project: Apache Jena
> Issue Type: Bug
> Components: ARQ
> Affects Versions: Jena 3.1.1
> Reporter: Rob Vesse
> Assignee: Andy Seaborne
>
> I have produced the following minimal query from an originally much larger
> query. When the optimise is applied to this it incorrectly double renames the
> variables inside of the {{FILTER NOT EXISTS}} clause leading to incorrect
> algebra.
> Query:
> {noformat}
> SELECT ?triangles ?openTriplets
> {
> {
> #subQ2: calculate #open-triplets
> SELECT (COUNT(?x) as ?openTriplets)
> WHERE {
> ?x ?a ?y .
> ?y ?b ?z .
> FILTER NOT EXISTS {?z ?c ?x}
> }
> }
> }
> {noformat}
> Output:
> {noformat}
> (project (?triangles ?openTriplets)
> (project (?openTriplets)
> (extend ((?openTriplets ?/.0))
> (group () ((?/.0 (count ?/x)))
> (filter (notexists
> (quadpattern (quad <urn:x-arq:DefaultGraphNode> ?//z ?//c
> ?//x)))
> (quadpattern
> (quad <urn:x-arq:DefaultGraphNode> ?/x ?/a ?/y)
> (quad <urn:x-arq:DefaultGraphNode> ?/y ?/b ?/z)
> ))))))
> {noformat}
> Note that we apply the quad transformation prior to applying the optimiser.
> Strangely enough I cannot reproduce the problem using pure Jena command line
> tools i.e. {{qparse}} although I note from the code that it applies quad
> transformation after applying optimisation. This suggests that it is a bug in
> how TransformScopeRename applies to quad form algebra.
> I can reproduce it with a unit test like so:
> {noformat}
> @Test
> public void filter_not_exists_scoping_03() {
> //@formatter:off
> Op orig = SSE.parseOp(StrUtils.strjoinNL("(project (?triangles
> ?openTriplets)",
> " (project (?openTriplets)",
> " (extend ((?openTriplets ?.0))",
> " (group () ((?.0 (count ?x)))",
> " (filter (notexists",
> " (quadpattern (quad
> <urn:x-arq:DefaultGraphNode> ?z ?c ?x)))",
> " (quadpattern",
> " (quad
> <urn:x-arq:DefaultGraphNode> ?x ?a ?y)",
> " (quad
> <urn:x-arq:DefaultGraphNode> ?y ?b ?z)",
> " ))))))"));
> Op expected = SSE.parseOp(StrUtils.strjoinNL("(project (?triangles
> ?openTriplets)",
> " (project (?openTriplets)",
> " (extend ((?openTriplets ?/.0))",
> " (group () ((?/.0 (count ?/x)))",
> " (filter (notexists",
> " (quadpattern (quad
> <urn:x-arq:DefaultGraphNode> ?/z ?/c ?/x)))",
> " (quadpattern",
> " (quad <urn:x-arq:DefaultGraphNode> ?/x ?/a ?/y)",
> " (quad <urn:x-arq:DefaultGraphNode> ?/y ?/b ?/z)",
> " ))))))"));
> //@formatter:on
>
> Op transformed = TransformScopeRename.transform(orig);
>
> Assert.assertEquals(transformed, expected);
> }
>
> @Test
> public void filter_not_exists_scoping_04() {
> //@formatter:off
> Op orig = SSE.parseOp(StrUtils.strjoinNL(
> " (project (?openTriplets)",
> " (extend ((?openTriplets ?.0))",
> " (group () ((?.0 (count ?x)))",
> " (filter (notexists",
> " (quadpattern (quad
> <urn:x-arq:DefaultGraphNode> ?z ?c ?x)))",
> " (quadpattern",
> " (quad
> <urn:x-arq:DefaultGraphNode> ?x ?a ?y)",
> " (quad
> <urn:x-arq:DefaultGraphNode> ?y ?b ?z)",
> " )))))"));
> Op expected = SSE.parseOp(StrUtils.strjoinNL(
> " (project (?openTriplets)",
> " (extend ((?openTriplets ?.0))",
> " (group () ((?.0 (count ?x)))",
> " (filter (notexists",
> " (quadpattern (quad
> <urn:x-arq:DefaultGraphNode> ?z ?c ?x)))",
> " (quadpattern",
> " (quad <urn:x-arq:DefaultGraphNode> ?x ?a ?y)",
> " (quad <urn:x-arq:DefaultGraphNode> ?y ?b ?z)",
> " )))))"));
> //@formatter:on
>
> Op transformed = TransformScopeRename.transform(orig);
>
> Assert.assertEquals(transformed, expected);
> }
> {noformat}
> The first test fails while the second passes. This implies that you need 2
> levels of projection to hit the bug.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
