GH-4920 SPARQLConnection.size() now uses count query #4972
Conversation
…nt in the repository. Just send a count query instead. Signed-off-by: Jerven Bolleman <jerven.bolleman@sib.swiss>
|
@hmottestad did you see this license failure before? |
|
|
||
| String sizeAsTupleQuery(Resource... contexts) { | ||
| String query = COUNT_EVERYTHING; | ||
| if (contexts != null && isQuadMode()) { |
There was a problem hiding this comment.
I think contexts should never be null, but contexts[0] can probably be null if the user is asking for the default context.
There was a problem hiding this comment.
RDF4J has the rdf4j:nil context and also a sesame one for addressing the default context. I believe it's a general issue with SPARQL that there is no way to address just the triples in the unnamed context. Jena also has their own: https://jena.apache.org/documentation/tdb/datasets.html#special-graph-names
Maybe we can test if either one of these returns results, and if not fallback to the old method?
There was a problem hiding this comment.
It's a problem only when the default graph in SPARQL is the union of all graphs, but this is what I've found most sensible for all applications that I've used.
There was a problem hiding this comment.
I will check that a null context[0] will work as well as the rdf4j:nil or semame:nil. For the cases where the remote uses a non union default graph the old case would also have returned 0.
| + "> { ?s ?p ?o}}"; | ||
| } else if (contexts.length > 0) { | ||
| String graphs = Arrays.stream(contexts) | ||
| .filter(Resource::isIRI) |
There was a problem hiding this comment.
What happens with blank nodes in our current implementation? Are blank node identifiers at all stable in some way?
There was a problem hiding this comment.
I SPARQL named graphs are not allowed to be blank nodes. So it could have worked if the stars aligned, but never reliably.
| @@ -100,6 +114,26 @@ public void testAddSingleContextHandling() throws Exception { | |||
| assertThat(sparqlUpdate).containsPattern(expectedAddPattern).containsPattern(expectedRemovePattern); | |||
| } | |||
|
|
|||
| @Test | |||
| public void testSizeQuery() throws Exception { | |||
There was a problem hiding this comment.
Do we have any end to end tests that actually spin up a SPARQL endpoint and runs operations against that?
There was a problem hiding this comment.
Unfortunately not that I am aware off
There was a problem hiding this comment.
I think in FedX federation part we have spin up a SPARQL embedded server for integration testing. Maybe you can borrow some ideas from there
I haven't seen that one before, but I have once experienced an old dependency suddenly failing the license check. I didn't figure out what was wrong last time, ended up just upgrading the dependency. Let me try to submit it to clearlydefined. Might take some time though :( |
CQ: https://gitlab.eclipse.org/eclipsefdn/emo-team/iplab/-/issues/14675 |
GitHub issue resolved #4920
Briefly describe the changes proposed in this PR:
SPARQLConnection.size() method should not fetch every statement in the repository. Just send a count query instead.
PR Author Checklist (see the contributor guidelines for more details):
mvn process-resourcesto format from the command line)