[ 
https://issues.apache.org/jira/browse/JENA-954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14572762#comment-14572762
 ] 

ASF subversion and git services commented on JENA-954:
------------------------------------------------------

Commit 4e8b4c1e9e8e25bddad33c11ec93030fee2d59b3 in jena's branch 
refs/heads/master from [~rvesse]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=4e8b4c1 ]

Fix a bug in OpAsQuery.asQuery() (JENA-954)

Some modifiers that can wrap a project (distinct, reduced and slice)
were being incorrectly moved from the sub-query to the parent query when
trying to round trip a SPARQL query through algebra form.

This commit modifies OpAsQuery so that the conversion of those algebra
operators checks whether we're already inside a project (and thus the
occurrence of these operators means we have a sub-query) and if so
converts the operator and its sub-tree into a sub-query on the parent
query.

With this commit test cases based upon JENA-954 all now pass


> OpAsQuery can move sub-query modifiers onto outer query
> -------------------------------------------------------
>
>                 Key: JENA-954
>                 URL: https://issues.apache.org/jira/browse/JENA-954
>             Project: Apache Jena
>          Issue Type: Bug
>          Components: ARQ
>    Affects Versions: Jena 2.13.0
>            Reporter: Rob Vesse
>            Assignee: Rob Vesse
>            Priority: Minor
>             Fix For: Jena 3.0.0
>
>         Attachments: Jena_954_Report.java
>
>
> Reported on the mailing list:
> http://s.apache.org/jena-algebra-roundtripping-bug
> Some queries roundtrip incorrectly through the {{Algebra.compile()}} to 
> {{OpAsQuery.asQuery()}} flow e.g.
> {noformat}
> SELECT (COUNT(*) as ?count) {
>   SELECT DISTINCT ?uri ?graph WHERE {
>     GRAPH ?graph {
>       ?uri ?p ?o .
>       }
>     } LIMIT 1
> }
> {noformat}
> Produces algebra:
> {noformat}
> project (?tripod_count_var)
>   (extend ((?tripod_count_var ?.0))
>     (group () ((?.0 (count)))
>       (distinct
>         (project (?uri ?graph)
>           (graph ?graph
>             (bgp (triple ?uri ?p ?o))))))))
> {noformat}
> Which round trips back to:
> {noformat}
> SELECT DISTINCT  (count(*) AS ?tripod_count_var)
> WHERE
>   { { SELECT  ?uri ?graph
>       WHERE
>         { GRAPH ?graph
>             { ?uri ?p ?o}
>         }
>     }
>   }
> {noformat}
> Note that the {{DISTINCT}} was incorrectly moved to the outer query
> The problem is that the conversion does not correct cope with the case of 
> being within a {{project}} and needs to spawn a sub-converter to cope as 
> {{OpProject}} already does



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to