RDF4J Bindings: StardogRepositoryConnection::remove is not working properly

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).


// ... 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 );


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


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

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

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.


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

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