[
https://issues.apache.org/jira/browse/JENA-705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14012616#comment-14012616
]
Andy Seaborne edited comment on JENA-705 at 5/29/14 7:56 PM:
-------------------------------------------------------------
JENA-577 introduced the problem.
The inner projections are not properly masking renamed variables. The ?z in
the first part is seen (as {{?/z}})in the second.
{noformat}
PREFIX : <http://example/>
SELECT * {
?s ?p ?o .
{ SELECT ?s { ?s :p ?z } }
{ SELECT ?s { ?s :q ?z } }
}
{noformat}
The first {{?s ?p ?o}} cause substitution evaluation of the next SELECT which
leaks {{?/z}} into the final clause. (no substitution evaluation of the first
SELECT causes it to short cut and do the projection properly.)
was (Author: andy.seaborne):
JENA-577 introduced the problem.
The inner projections are not properly masking renamed variables. The ?z in
the first part is seen (as {{?/z}})in the second.
{noformat}
PREFIX : <http://example/>
SELECT * {
{ SELECT ?s { ?s :p ?z } }
{ SELECT ?s { ?s :q ?z } }
}
{noformat}
> Sequence of joins of sub-queries gives incorrect answer
> -------------------------------------------------------
>
> Key: JENA-705
> URL: https://issues.apache.org/jira/browse/JENA-705
> Project: Apache Jena
> Issue Type: Bug
> Components: ARQ
> Affects Versions: Jena 2.11.1
> Reporter: Rob Vesse
> Assignee: Andy Seaborne
> Priority: Critical
> Attachments: data-subset.ttl, data.ttl, query-subset.rq, query.rq,
> test-data.ttl, test-query.rq
>
>
> This issue comes out of a stack overflow question at
> http://stackoverflow.com/questions/23899841/jenas-subquery-intersection-returns-empty-contrary-to-the-results-from-protege?noredirect=1#comment36813625_23899841
> about differences between query results in Protege and Jena
> From both the SO question and my own experimentation this does indeed appear
> to be a bug.
> I'll attach the query and dataset afterwards but essentially the following
> behaviour can be observed.
> With 2.11.0 the following returns results:
> {noformat}
> > ./sparql --query query.rq --data data.ttl
> ---------------------------------------------------------------------------------------------------------------------------------------
> | offering
> |
> =======================================================================================================================================
> |
> <http://PricingAPIAmazonOnDemandOfferings.com#hs1.8xlarge_3440_TIME247806284122937linux-AmazonOnDemandInstance_TIME247806284128497>
> |
> |
> <http://PricingAPIAmazonOnDemandOfferings.com#m1.xlarge_3044_TIME247806261045248linux-AmazonOnDemandInstance_TIME247806261052518>
> |
> |
> <http://PricingAPIAmazonOnDemandOfferings.com#cr1.8xlarge_3330_TIME247806279000311linux-AmazonOnDemandInstance_TIME247806279016134>
> |
> |
> <http://PricingAPIAmazonOnDemandOfferings.com#m1.medium_3000_TIME247806258807012linux-AmazonOnDemandInstance_TIME247806258833953>
> |
> |
> <http://PricingAPIAmazonOnDemandOfferings.com#m2.xlarge_3264_TIME247806274243312linux-AmazonOnDemandInstance_TIME247806274255286>
> |
> |
> <http://PricingAPIAmazonOnDemandOfferings.com#c3.8xlarge_3154_TIME247806266383402linux-AmazonOnDemandInstance_TIME247806266391099>
> |
> |
> <http://PricingAPIAmazonOnDemandOfferings.com#m1.large_3022_TIME247806259925275linux-AmazonOnDemandInstance_TIME247806259933827>
> |
> |
> <http://PricingAPIAmazonOnDemandOfferings.com#c1.xlarge_3198_TIME247806269972105linux-AmazonOnDemandInstance_TIME247806269986217>
> |
> |
> <http://PricingAPIAmazonOnDemandOfferings.com#i2.2xlarge_3374_TIME247806281161573linux-AmazonOnDemandInstance_TIME247806281167987>
> |
> |
> <http://PricingAPIAmazonOnDemandOfferings.com#cc2.8xlarge_3220_TIME247806271984550linux-AmazonOnDemandInstance_TIME247806271997379>
> |
> |
> <http://PricingAPIAmazonOnDemandOfferings.com#hi1.4xlarge_3462_TIME247806285100936linux-AmazonOnDemandInstance_TIME247806285106495>
> |
> |
> <http://PricingAPIAmazonOnDemandOfferings.com#i2.xlarge_3352_TIME247806280140383linux-AmazonOnDemandInstance_TIME247806280147225>
> |
> |
> <http://PricingAPIAmazonOnDemandOfferings.com#c3.4xlarge_3132_TIME247806265310896linux-AmazonOnDemandInstance_TIME247806265318593>
> |
> |
> <http://PricingAPIAmazonOnDemandOfferings.com#m2.2xlarge_3286_TIME247806275687432linux-AmazonOnDemandInstance_TIME247806275695557>
> |
> |
> <http://PricingAPIAmazonOnDemandOfferings.com#m2.4xlarge_3308_TIME247806277291059linux-AmazonOnDemandInstance_TIME247806277311157>
> |
> |
> <http://PricingAPIAmazonOnDemandOfferings.com#c3.2xlarge_3110_TIME247806264234541linux-AmazonOnDemandInstance_TIME247806264242239>
> |
> |
> <http://PricingAPIAmazonOnDemandOfferings.com#i2.4xlarge_3396_TIME247806282156677linux-AmazonOnDemandInstance_TIME247806282162664>
> |
> |
> <http://PricingAPIAmazonOnDemandOfferings.com#i2.8xlarge_3418_TIME247806283147932linux-AmazonOnDemandInstance_TIME247806283153491>
> |
> |
> <http://PricingAPIAmazonOnDemandOfferings.com#m3.2xlarge_2956_TIME247806256606408linux-AmazonOnDemandInstance_TIME247806256614533>
> |
> ---------------------------------------------------------------------------------------------------------------------------------------
> {noformat}
> However with 2.11.1 or with current trunk it returns no results:
> {noformat}
> > ./sparql --query query.rq --data data.ttl
> ------------
> | offering |
> ============
> ------------
> {noformat}
> However if we use the reference engine i.e.
> {noformat}
> > ./sparql --query query.rq --data data.ttl --engine=ref
> {noformat}
> Or disable the optimiser i.e.
> {noformat}
> > ./sparql --query query.rq --data data.ttl --set arq:optimization=false
> {noformat}
> Or disable the index join strategy i.e.
> {noformat}
> > ./sparql --query query.rq --data data.ttl --set
> > arq:optIndexJoinStrategy=false
> {noformat}
> Then we do get the same results as 2.11.0 returned
> Therefore this looks to be a change in behaviour in index join strategy
> introduced in 2.11.1
--
This message was sent by Atlassian JIRA
(v6.2#6252)
