RDF4J Bindings: StardogRepositoryConnection::remove is not working properly

Support Bug
1

I want to delete any statement that has a specific IRI as the predicate or object (with any context) but the StartdogRepositoryConnection is not actually doing what it is supposed to do.

Steps to reproduce

// ... repository initialization

RepositoryConnection connection = stardogRepository.getConnection();

// Remove all statements with `someIRI` as the object
connection.remove( (Resource) null, null, someIRI );
// Remove all statements with `someIRI` as the predicate
connection.remove( (Resource) null, someIRI, null );

Expected results

Any statement, from any context with the specified patterns is deleted.

Actual results

Nothing (maybe just the general graph is affected).

Workaround

// ... repository initialization

RepositoryConnection connection = stardogRepository.getConnection();

try ( RepositoryResult<Statement> statementsWithSomeIRIAsAnObject = connection.getStatements( null, null, someIRI, false ) ) {
  connection.remove( statementsWithSomeIRIAsAnObject );
}

try ( RepositoryResult<Statement> statementsWithSomeIRIAsAPredicate = connection.getStatements( null, someIRI, null, false ) ) {
  connection.remove( statementsWithSomeIRIAsAPredicate );
}

Environment

Stardog: 5.0.3
Stardog/RDF4J bindings: com.complexible.stardog.rdf4j:stardog-rdf4j:5.0.3

Notes

  • I turned on the query.all.graphs option but the results are the same.
2

Hi, thanks for the detailed bug report, and apologies for taking so long to get to this thread.

I am able to reproduce your issue with specific data (looks like it needs to be in a named graph). We will look into this for the next release.

EDIT: I have created Issue #4261 to address this.

1 Like
3

Just upgraded to 5.0.4 since the CHANGELOG says that this bug was fixed on that version. But after doing some testing the bug seems to still be present.

4

Hi,

Can you share some code that (using 5.0.4) does not behave the way you want it to? I was just able to throw together a test case with 5.0.4 that shows this bug to be fixed

5

Just tested it again and the bug seems to be gone in version 5.3.4. Thanks for taking care of it :+1: