[
https://issues.apache.org/jira/browse/JENA-954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Vesse resolved JENA-954.
----------------------------
Resolution: Fixed
Should now be fixed, conversion of {{slice}}, {{distinct}} and {{reduced}} all
now check whether they are within a project and thus whether their appearance
must denote a sub-query. If this is the case then they convert their portion
of the algebra tree as a sub-query.
The test case given (and variations there on) now passes correctly
> 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)
