[ 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:04 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))) Without also binding the empty table to ?foo 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)