[
https://issues.apache.org/jira/browse/JENA-1468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16332764#comment-16332764
]
Rick edited comment on JENA-1468 at 1/19/18 7:03 PM:
-----------------------------------------------------
Hi Andy,
Thanks for your response.
I should've perhaps been clearer. We're using ARQ/SSEs to parse the queries
and transform them, before converting them back into SPARQL for execution on a
different query engine; so I don't know if this issue effects Fuseki.
{quote} "Not essential for problem just to show we can't optimise it away. " -
could you explain a bit more? It is still a join and there are no variables in
common because the right-hand-side is a partial evaluation with no columns (or
rows).{quote}
Sorry my choice of words there probably wasn't ideal, you're right that it can
indeed be optimised away if the query is rewritten to produce this:
SELECT ?foo WHERE {
}
but what we're seeing is that the query being rewritten to produce:
SELECT ?foo WHERE {
?foo ?bar ?baz .
VALUES ( ) { }
}
Note how the values has lost the binding to {{?foo}}, which means it doesn't
fail its unification, so instead of getting no results, we get all ?foo. I
suspected this is because {{(table empty)}} is being simplified too early,
however it might also be an issue in our transformation code, though we notice
this problem even when we supply identity as a transformation.
A complicating factor in this is that we're not using the SSE visitor API, as
we're driving this from clojure. Where it was "simpler" for us to build a
clojure.zip/zipper on top of Item/ItemList, though that effectively means as
the tree is walked every node is rebuilt in a new ItemList. So it seems there
could also be a bug in how the tree gets reassembled.
However I find it curious how this:
{{Algebra.compile(QueryFactory.create("SELECT ?foo WHERE { ?foo ?bar ?baz .
VALUES ?foo { }}"));}}
producing this:
{{(project (?foo)}}
{{ (join}}
{{ (bgp (triple ?foo ?bar ?baz))}}
{{ (table empty))) }}
Is valid.
Many thanks for your help.
was (Author: moynihan):
Hi Andy,
Thanks for your response.
I should've perhaps been clearer. We're using ARQ/SSEs to parse the queries
and transform them, before converting them back into SPARQL for execution on a
different query engine; so I don't know if this issue effects Fuseki.
{quote} "Not essential for problem just to show we can't optimise it away. " -
could you explain a bit more? It is still a join and there are no variables in
common because the right-hand-side is a partial evaluation with no columns (or
rows).{quote}
Sorry my choice of words there probably wasn't ideal, you're right that it can
indeed be optimised away if the query is rewritten to produce this:
SELECT ?foo WHERE {
}
but what we're seeing is that the query being rewritten to produce:
SELECT ?foo WHERE {
?foo ?bar ?baz .
VALUES ( ) { }
}
Note how the values has lost the binding to {{?foo}}, which means it doesn't
fail its unification, so instead of getting no results, we get all ?foo. I
suspected this is because {{(table empty)}} is being simplified too early,
however it might also be an issue in our transformation code, though we notice
this problem even when we supply identity as a transformation.
A complicating factor in this is that we're not using the SSE visitor API, as
we're driving this from clojure. Where it was "simpler" for us to build a
clojure.zip/zipper on top of Item/ItemList, though that effectively means as
the tree is walked every node is rebuilt in a new ItemList. So it seems there
could also be a bug in how the tree gets reassembled.
However I find it curious how this:
{{Algebra.compile(QueryFactory.create("SELECT ?foo WHERE { ?foo ?bar ?baz .
VALUES ?foo { }}"));}}
producing this:
{{
(project (?foo)
(join
(bgp (triple ?foo ?bar ?baz))
(table empty)))
}}
Is valid.
Many thanks for your help.
> Empty VALUES clauses lose variable bindings when compiled to a SSE
> ------------------------------------------------------------------
>
> Key: JENA-1468
> URL: https://issues.apache.org/jira/browse/JENA-1468
> Project: Apache Jena
> Issue Type: Bug
> Components: ARQ
> Affects Versions: Jena 3.1.1, Jena 3.2.0, Jena 3.3.0, Jena 3.4.0, Jena
> 3.5.0, Jena 3.6.0
> Reporter: Rick
> Priority: Major
> Labels: SPARQL, sse
>
> Given a SPARQL query like this:
> SELECT ?foo WHERE {
> ?foo ?bar ?baz . # Not essential for problem just to show we can't
> optimise it away.
> VALUES ?foo { }
> }
> If you compile it into an SSE with something like this:
> {{Algebra.compile(QueryFactory.create("SELECT ?foo WHERE \{ ?foo ?bar ?baz .
> VALUES ?foo { }}"));}}
> You end up with a semantically different SSE:
> {{(project (?foo)}}
> {{ (join}}
> {{ (bgp (triple ?foo ?bar ?baz))}}
> {{ (table empty)))}}
> Note how "(table empty)" has lost the ?foo binding, which means that this
> query returns all results for ?foo, where it should return no results.
> I'm not sure how this query should be expressed in SSE form I'd suggest:
> {{(table (vars ?foo) empty)}}
> Though currently this will get simplified in [code like
> this|https://github.com/apache/jena/blob/94eb3fc99ba1ff3991a629fffa6e6cf8b52d6c53/jena-arq/src/main/java/org/apache/jena/sparql/sse/builders/BuilderTable.java#L55-L64]
> into an EmptyTable if you do something like:
> {{BuilderTable.build(Item.createList((SSE.parse("(table (vars ?foo)
> empty)")));}}
> Additionally it appears quite a bit of code carries through this assumption
> that an [empty table will never have a
> binding|https://github.com/apache/jena/blob/94eb3fc99ba1ff3991a629fffa6e6cf8b52d6c53/jena-arq/src/main/java/org/apache/jena/sparql/algebra/table/TableEmpty.java#L57].
> As far as I can tell this issue effects many prior versions of JENA including
> 3.6.0.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
