On 4 June 2015 at 12:56, Andy Seaborne <[email protected]> wrote:
> On 04/06/15 12:28, Rob Vesse wrote:
>
>> Rick
>>
>> Yes this does look like a bug
>>
>
> Agreed. If the DISTINCT is being pulled up, it's wrong.
> LIMIT is missing as well.
>
> A slight but though ...
>
> Where does "?tripod_count_var" come from?
>
Apologies this is a copy paste error, when assembling the report.
?tripod_var_count is just ?count.
R.
> The algebra shown names a variable not in the query.
>
> The input query has algebra:
>
> (project (?count)
> (extend ((?count ?.0))
> (group () ((?.0 (count)))
> (slice _ 1
> (distinct
> (project (?uri ?graph)
> (graph ?graph
> (bgp (triple ?uri ?p ?o)))))))))
>
> Andy
>
>
>
>> Please bear in mind however that conversion to algebra does NOT guarantee
>> to round trip because some parts of a query do not end up in the algebra
>> and so OpAsQuery has simply no way to reconstruct the exact original query
>>
>> For example:
>>
>> SELECT * {
>> SELECT ?x { ?x a ?type }
>> }
>>
>> Would round trip back to just:
>>
>> SELECT ?x { ?x a ?type }
>>
>>
>> There are also other cases where things could move around slightly, for
>> example a BIND is potentially indistinguishable from a SELECT expression
>> depending on the structure of the query.
>>
>> I have filed this as JENA-954 -
>> https://issues.apache.org/jira/browse/JENA-954
>>
>> Thanks for reporting this,
>>
>> Rob
>>
>> On 04/06/2015 11:45, "Rick Moynihan" <[email protected]> wrote:
>>
>> Hi all,
>>>
>>> I have been playing around using ARQ to rewrite queries with Jena 2.13.0
>>> and have encountered what appears to be a bug when roundtripping a valid
>>> SPARQL query through to an SSE and back out as SPARQL.
>>>
>>> The original SPARQL query is this:
>>>
>>> SELECT (COUNT(*) as ?count) {
>>> SELECT DISTINCT ?uri ?graph WHERE {
>>> GRAPH ?graph {
>>> ?uri ?p ?o .
>>> }
>>> } LIMIT 1
>>> }
>>>
>>> This parses into the following SSE by going through QueryFactory.create
>>> ->
>>> Algebra.compile :
>>>
>>> #<OpProject (project (?tripod_count_var)
>>> (extend ((?tripod_count_var ?.0))
>>> (group () ((?.0 (count)))
>>> (distinct
>>> (project (?uri ?graph)
>>> (graph ?graph
>>> (bgp (triple ?uri ?p ?o))))))))
>>>
>>> To my eye this looks correct so far... next we round trip it back into a
>>> SPARQL query by using OpAsQuery.asQuery that results in:
>>>
>>> #<Query SELECT DISTINCT (count(*) AS ?tripod_count_var)
>>> WHERE
>>> { { SELECT ?uri ?graph
>>> WHERE
>>> { GRAPH ?graph
>>> { ?uri ?p ?o}
>>> }
>>> }
>>> }
>>>
>>>>
>>>>
>>> This now seems broken... asQuery has mixed the inner select distinct
>>> onto
>>> the outer one. This appears to happen with all sub selects. I suspect
>>> it
>>> might be due to OpAsQuery.asQuery building only Query object which is
>>> somehow being reused for all sub queries.
>>>
>>> I took a look in the unit tests and found that some of the test queries
>>> in
>>> TestOpAsQuery are also subject to this bug e.g. the query on line 223:
>>>
>>> SELECT ?key ?agg WHERE { { SELECT ?key (COUNT(*) AS ?agg) { ?key ?p ?o }
>>> GROUP BY ?key } }
>>>
>>> Though the tests don't seem to currently test for this kind of thing.
>>>
>>> Can anyone confirm that this is a bug?
>>>
>>> Kind regards,
>>>
>>> R.
>>>
>>
>>
>>
>>
>>
>
