Yes, we're agreed :-) R.
On 4 June 2015 at 13:07, Andy Seaborne <[email protected]> wrote: > I've written an example and attached it to JENA-954 > > Rick: could you check we are agreed here please? > > Andy > > > On 04/06/15 12:56, Andy Seaborne 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? >> >> 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. >>>> >>> >>> >>> >>> >>> >> >
