[
https://issues.apache.org/jira/browse/JENA-1468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16332916#comment-16332916
]
Andy Seaborne commented on JENA-1468:
-------------------------------------
And there was I wondering/hoping you were reading the SSE with the Clojure
reader :-)
Note that the variable declaration on a table isn't very strong - the table
isn't obliged to have the bindings. See {{ UNDEF }}.
It is only the printing that causes the {{ (table empty)}] - the actual algebra
has {{(table (vars ?foo))}}. However, forcing it to a real {{(table empty)}}
happens on printing as linked to above. This is wrong (syntax round trip is
not preserved) but harmless. It spills over into {{Op.equals}} which tests the
values.
A quick experiment on the code and it looks like the writer can be changed to
output {{(table (vars ?foo))}}. Further testing needed.
But it makes no evaluation difference - in SPARQL, if you join an intermediate
result of zero rows with anything, the result is zero rows. Variables don't
matter (this isn't SQL and SQL null!).
Try your code on {{ VALUES ?x { undef } }} -- that is one row, no columns (the
join identity in SPARQL syntax), making the {{?x}} irrelevant. You can join
non-matching sub-results in SPARQL. Unification (if I understand that term in
your context) with zero rows is zero rows. Zero rows is the algebra (pun!)
multiplicative zero. It is the same intermediate value as {{ VALUES ?z { } }}
or {{ VALUES (?x ?z { (undef undef) } }}.
{{ VALUES ( ) { } }} is way to write "no rows of no variables". The SPARQL
execution by that "other engine" should by zero rows. Yes, the {{?foo{} }} is
lost but variable declarations are there to align the list of values and there
aren't any.
> 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)
