[JENA-633] optimizer sequences instead of joins / subqueries with limits project more results than they should

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: Jena 2.11.0
• Fix Version/s: Jena 2.11.2
• Component/s: ARQ, Jena
• Labels: optimization sparql
• Assignee: Andy Seaborne
• Reporter: Joshua Taylor
• Created: 03/Feb/14 18:11
• Updated: 10/Jun/14 12:51
• Resolved: 08/Feb/14 17:36

Description

A subquery with `limit 1` specified can `leak` more values to the surrounding query. Rob Vesse tracked this down to a difference between the basic algebra and the optimized algebra [1] . One query has the following basic and optimized Ops; the "join" in the former shouldn't get turned into a "sequence" in the latter.

Basic:
(join
  (bgp (triple ?resource <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <urn:ex:Thing>))
  (slice _ 1
    (project (?resource ?p)
      (order (?p)
        (bgp (triple ?resource <urn:ex:p> ?p))))))

Optimized:
(sequence
  (bgp (triple ?resource <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <urn:ex:Thing>))
  (project (?resource ?p)
    (top (1 ?p)
      (bgp (triple ?resource <urn:ex:p> ?p)))))

[1] http://answers.semanticweb.com/questions/26343/outer-query-results-include-more-values-than-subquery-with-limit-n-produces/26344

Issue Links

• relates to: JENA-711 LIMIT on inner query incorrectly applied to outer query
• relates to: JENA-709 Index join strategy may need to be more conservative when some sequence elements are potentially expensive