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

Simplify SPARQL algebra Projection handling #2990

Closed
abrokenjester opened this issue Apr 12, 2021 · 1 comment
Closed

Simplify SPARQL algebra Projection handling #2990

abrokenjester opened this issue Apr 12, 2021 · 1 comment
Assignees
Labels
📶 enhancement issue is a new feature or improvement M3 📦 sparql affects the SPARQL parser / engine
Milestone

Comments

@abrokenjester
Copy link
Contributor

abrokenjester commented Apr 12, 2021

Related to #2985

For the following query:

select (?foo as ?bar) where { ?foo <foo:bar> "bar" }

We produce the following algebra tree:

Projection
   ProjectionElemList
      ProjectionElem "foo" AS "bar"
   Extension
      ExtensionElem (bar)
         Var (name=foo)
      StatementPattern
         Var (name=foo)
         Var (name=_const_d75d935f_uri, value=foo:bar, anonymous)
         Var (name=_const_17c13_lit_e2eec718_0, value="bar", anonymous)

Note that the aliasing of "foo" to "bar" is represented twice here: once as an ExtensionElem, once as an aliased ProjectionElem.

The ProjectionElem in our algebra predates sparql and its evaluation (in ProjectionIterator) has mechanisms to map source bindings to target bindings that we effectively don't need anymore, since the mapping is handled by the extension already. We should look into simplifying this part of the algebra and remove the distinction between source and target name in the ProjectionElem. This will make the intent of the algebra clearer, and likely allow us to improve performance as well, as the ProjectionIterator can be simplified.

@abrokenjester abrokenjester added 📶 enhancement issue is a new feature or improvement 📦 sparql affects the SPARQL parser / engine labels Apr 12, 2021
@abrokenjester abrokenjester added this to the 4.0.0 milestone Apr 12, 2021
@abrokenjester abrokenjester added the ⛔ Not backwards compatible A change that breaks backwards compatibility and needs a major release label Apr 12, 2021
@abrokenjester abrokenjester self-assigned this Feb 28, 2022
@abrokenjester
Copy link
Contributor Author

Alternatively we should look into removing the Extension where the projection itself already takes care of the aliasing.

Also as a possible complication is that handling of construct queries currently heavily relies on projection itself supporting aliasing.

@abrokenjester abrokenjester removed the ⛔ Not backwards compatible A change that breaks backwards compatibility and needs a major release label Feb 28, 2022
abrokenjester added a commit that referenced this issue Mar 4, 2022
abrokenjester added a commit that referenced this issue Mar 6, 2022
@hmottestad hmottestad added the M3 label Apr 6, 2022
patrickwyler pushed a commit to patrickwyler/rdf4j that referenced this issue Jun 20, 2022
patrickwyler pushed a commit to patrickwyler/rdf4j that referenced this issue Jun 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
📶 enhancement issue is a new feature or improvement M3 📦 sparql affects the SPARQL parser / engine
Projects
None yet
Development

No branches or pull requests

2 participants