Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SPARQL: Variables from outside group are visible inside group #1405

Closed
cygri opened this issue May 5, 2019 · 3 comments · Fixed by #1616
Closed

SPARQL: Variables from outside group are visible inside group #1405

cygri opened this issue May 5, 2019 · 3 comments · Fixed by #1616
Assignees
Labels
🐞 bug issue is a bug specification issues related to compliance to standards and external specs
Milestone

Comments

@cygri
Copy link

cygri commented May 5, 2019

The following query's query pattern has two group graph patterns:

SELECT * {
  { BIND ("a" AS ?a) }
  { BIND (?a AS ?b) } 
}

According to the SPARQL spec, the result of the query is defined as the result of evaluating each group independently, and then joining the results:

  • Evaluating the first group should yield a single solution with ?a bound to "a".
  • Evaluating the second group should yield a single solution with no variables bound. Each group is evaluated independently, and ?a is not bound within the group, so the BIND leaves ?b unbound.
  • Joining both results should yield a single solution with ?a bound to "a".

In RDF4J, however, the query returns a single solution with both ?a and ?b bound to "a". This is incorrect.

Similar problems exists for other language constructs. For example, changing the second group to an OPTIONAL shows the same problem. But changing it to a subquery does not.

@abrokenjester abrokenjester added 🐞 bug issue is a bug specification issues related to compliance to standards and external specs labels May 11, 2019
@abrokenjester abrokenjester added this to the 2.5.2 milestone May 11, 2019
@abrokenjester
Copy link
Contributor

Can you give an example query with an optional pattern that shows this issue? Reason I ask is that first glance the issue appears to be specific to how BIND is processed, but I may be overlooking something.

@abrokenjester abrokenjester self-assigned this May 16, 2019
@cygri
Copy link
Author

cygri commented May 16, 2019

What I meant is, it's not just group graph patterns that are affected, but if the second group was replaced by, say, OPTIONAL { BIND (?a AS ?b) }, it shows the same problem (or so I seem to remember—haven't tried it again now).

It may well be specific to BIND.

@abrokenjester
Copy link
Contributor

I have just realized that this fix is incomplete: while all the mechanics are put in place, the query planner doesn't actually use the new logic to determine what join strategy to use. 🤦‍♂️

That'll teach me for adding a fix without a regression test.

@abrokenjester abrokenjester removed this from the 2.5.4 milestone Aug 4, 2019
@abrokenjester abrokenjester added this to the 3.0.0 milestone Aug 18, 2019
@abrokenjester abrokenjester modified the milestones: 3.0.0, 3.1.0 Aug 20, 2019
abrokenjester added a commit that referenced this issue Oct 18, 2019
use merge-join for group patterns to handle scope, with special case
exception for FILTER (NOT) EXISTS
@abrokenjester abrokenjester modified the milestones: 3.1.0, 3.0.2 Oct 18, 2019
abrokenjester added a commit that referenced this issue Oct 22, 2019
* GH-1405 fixed scope handling in join iterator

use merge-join for group patterns to handle scope, with special case
exception for FILTER (NOT) EXISTS

* GH-1405 only add scoping braces if arg is a group graph pattern

* GH-1405 fix NosuchElementException in MergeIteration and skip for all
filters
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🐞 bug issue is a bug specification issues related to compliance to standards and external specs
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants