[
https://issues.apache.org/jira/browse/JENA-1468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16337960#comment-16337960
]
Andy Seaborne commented on JENA-1468:
-------------------------------------
Yes - that makes sense if you are you turning the algebra into a string and
back again by reading it in. It's the printing that's broken. Without
printing, using the Op directly round trips because internally the algebra is
correct - the {{(table (vars ?foo))}} form.
Here's the two cases: {{x1}} is what the printing as a string for the query
should be and {{x2}} what it currently is:
{noformat}
public static void main(String ... a) {
String x1 = "(project (?foo) (join (bgp (triple ?foo ?bar ?baz)) (table
(vars ?foo) )))";
String x2 = "(project (?foo) (join (bgp (triple ?foo ?bar ?baz)) (table
empty) ))";
Op op1 = SSE.parseOp(x1);
Op op2 = SSE.parseOp(x2);
System.out.println(op1);
System.out.println(op2);
Query query1 = OpAsQuery.asQuery(op1);
Query query2 = OpAsQuery.asQuery(op2);
System.out.println(query1);
System.out.println(query2);
}
{noformat}
giving
{noformat}
SELECT ?foo
WHERE
{ ?foo ?bar ?baz
VALUES ?foo { }
}
SELECT ?foo
WHERE
{ ?foo ?bar ?baz
VALUES ( ) {
}
}
{noformat}
fixing the printing and I get the {{VALUES ?foo}} form because it is {{x1}} not
{{x2}}. PR to follow.
----
There is one remaining issue for you though: the VALUES block can't be removed
in either case because it is no rows, and joining it to anything results in no
rows. If it was N rows, of no columns, the join is N copies of the results of
the other pattern (the triple pattern here).
> 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)
