Bovlb patch 1 by bovlb · Pull Request #2931 · RDFLib/rdflib (original) (raw)
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 andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation5 Commits7 Checks20 Files changed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
Summary of changes
The following SPARQL where clause:
?s :hasIngredient [:name "chicken"], [:name "butter"] .
should be parsed as:
_:1 :name "butter" .
_:2 :name "chicken" .
?s :hasIngredient _:1 .
?s :hasIngredient _:2
but was instead being parsed as:
_:1 :name "chicken" .
_:1 :name _:2 .
_:2 :name "butter" .
?s :hasIngredient _:1
I fixed the bug and added a new test.
Checklist
- Checked that there aren't other open pull requests for
the same change. - Checked that all tests and type checking passes.
- If the change has a potential impact on users of this project:
- Added or updated tests that fail without the change.
- Updated relevant documentation to avoid inaccuracies.
- Considered adding additional documentation.
- Considered granting push permissions to the PR branch,
so maintainers can fix minor issues and keep your PR up to date.
coverage: 90.293% (-0.006%) from 90.299%
when pulling e287709 on bovlb:bovlb-patch-1
into 9c469b5 on RDFLib:main.
Wow. Thanks. I can't believe a bug like that in the SPARQL parser has existed undetected for so long.
Was the bug only when the two bnodes are on the same line? Did it have the same problem when thee bnodes were separated over two lines like this?
?s :hasIngredient [:name "chicken"],
[:name "butter"] .
Wow. Thanks. I can't believe a bug like that in the SPARQL parser has existed undetected for so long.
I didn't believe it at first myself.
Was the bug only when the two bnodes are on the same line? Did it have the same problem when thee bnodes were separated over two lines like this?
That doesn't change the token sequence, so it's the same problem.
The bug was that we were assuming a comma implied we should repeat the third-last and second-last results as the subject and object of the new triple. This assumption didn't hold when we had inserted a triple from a blank node.
