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 join tests & fixes #127
Conversation
Fix for numeric candidate Subject join via conformance to RDFJS Store spec
should(items[0]['?s']['value']).equal('http://ex.com/bob'); | ||
}); | ||
|
||
it.skip('should join quad patterns with numeric candidate', async function () { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I forgot to mention, this test is skipped because it also fails on LevelDOWN and RocksDB. However without the fix in quadstore it fails everywhere.
This is very weird! When run separately, the two |
In the meantime, the RDF 1.1 spec doesn't seem to allow |
Indeed not. However, it seems that when the variables candidate bindings are being explored, Comunica nevertheless can end up calling |
@rubensworks a couple of questions for you:
Comunica seems to invoke the
What's strange is that if I run two separate queries, one for each of those patterns, I get the expected results and I am able to join them by hand. As all the backends are abstracted via the |
Thanks for having a look @jacoscaz. With regard to the Leveldown behaviour being different to Memdown, I've been experimenting with a hypothesis that there is a race condition – in Memdown the race is always won because of the very fast query response, on the microtask queue. In particular, I thought it was suspicious that quadstore's
|
Quick update on this - I've tried refactoring |
Indeed, strictly speaking, RDF does not allow literals in subject position. Furthermore, always checking term types before binding may introduce some performance overhead, so Comunica expects that the store simply returns empty results in those cases. This should be in line with the semantics of RDF/JS, where generalized RDF is also possible by default.
In case you are manually creating asynciterators, you could try enabling the |
Sounds good! I was not aware of the generalized RDF mode.
Good idea, I'll test this shortly. Thanks! |
I think I've found the culprit. There are cases in which |
@gsvarovsky I've just pushed the fix for the broken |
@gsvarovsky just pushed the fix for breaking queries when in generalized rdf mode with a literal subject. I'll release tomorrow or whenever you get a chance to validate these fixes. Just FYI, a more definitive fix (and potentially support for generalized rdf mode, not sure yet) will come in v8.0, for which I'm planning a significant upheaval of the (de)serialization mechanism that will save a ton of storage space and should get us much closer to the raw performance of the |
Super! I've tested locally using the quadstore unit tests and m-ld's unit test suite with Memdown. I'm buried in a branch which is not ready for integration tests (where persistence is tested), so if you don't mind, I'll take it on faith that Leveldown works too, for now. |
Trying to track down some issues with SPARQL joins. There are two problems; I have only fixed one. See
test/sparql/sparql.select.join.js
:should join quad patterns
) passes its test only in MemDOWN. I have scratched my head about why this might be but to no avail. @jacoscaz it would be great if you could have a quick look.match
API in quadstore is more restrictive than that in the RDFJSStore
API. It appears that Comunica relies upon the looser definition taking Terms for all positions.