-
Notifications
You must be signed in to change notification settings - Fork 565
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 Sub-query inside sub-query fails #1722
Comments
I have found a method and solution to solve this particular problem. I have noticed that the when the multiple SELECT* is introduced, the nested Select* works but the results are not passed to the above SparQl query |
To solve this there are two possible paths: Following the path b may lead to change in the way in some other queries are parsed and evaluated. |
Now if we change the query in the preprocessing , lets take the example of the above query itself, SELECT * print(json.dumps(results, indent=4)) Now the results of the inner SELECT* must be passed to the outer SELECT* So now one way is to remove all such SELECT* which occurs consecutively as the remove one of them will have no effect on the query. But this may lead to some discrepancy. So the final thing that we can do is we can travel back to depth of all such nested SELECT* and then finally find the missing variables for which the query is run and then replacing * with these missing values in all the values on the tree. |
Fixing use of `SELECT *` in sub-select within `SELECT *` parent query as discovered in #1722. Now when an instance of `SELECT *` is encountered, the query tree/plan builder now correctly considers the projected variables of any sub-select statements when deciding which variables should be projected out. Fixes <#1722>.
When I write a query which has a sub-query inside a sub-query (as per the following example) I don't get the results I would expect back.
This yields the following output:
However, if I remove one level of sub-query from the SPARQL query I end up with results that I agree with:
I get the result I would have expected from the first query:
I've tested both queries in Apache JENA and get the results that I'd expect so I suspect that this is a symptomatic of a bug in rdflib's SPARQL querying functionality somewhere.
version info:
rdflib 6.1.1
python 3.9.0
The text was updated successfully, but these errors were encountered: