Skip to content
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

DROP GRAPH <non-existing-graph-in-repo> deletes entire dataset on native store #1548

Closed
vujasm opened this issue Sep 19, 2019 · 9 comments
Assignees
Labels
bug
Milestone

Comments

@vujasm
Copy link

@vujasm vujasm commented Sep 19, 2019

Hello,

I discovered a major bug with RDF4J server, version 3.0.0 and version
2.5.3+0adb5d9, that causes ALL named graphs to be permanently removed from a repository.

On version 2.5.3 it is caused with these steps:

  1. I have created few named graphs using INSERT DATA command via Sparql Update protocol
INSERT DATA
  { 
    GRAPH <urn:idea:1> 
      { 
triples
      } 
  }


INSERT DATA
  { 
    GRAPH <urn:idea:2> 
      { 
triples
      } 
  }

INSERT DATA
  { 
    GRAPH <urn:idea:3> 
      { 
triples
      } 
  }

And few more with uri <urn:idea:4> , <urn:idea:5> , <urn:idea:6> , etc.

  1. Then, I wanted to drop/remove one of graphs , e.g. <urn:idea:5> , and I executed DROP GRAPH <urn:idea:5>
    It works fine -- <urn:idea:5> has been removed from the repository.

  2. But now, if I use DROP GRAPH for a named graph that is not in a repository, e.g. DROP GRAPH <urn:idea:1000>, the result is that all named graphs are removed and context set gets totally empty.

With version 3.0.0. happens something similar. If I use DROP GRAPH for a named graph that is not in my repository, e.g. DROP GRAPH <urn:idea:1000>, then the context-set remains as it was before the drop command, as expected, BUT any next execution of DROP GRAPH command for named graphs that are in the repository, is not working at all (does not remove the named graph). Further, if I add a new named graph e.g. <urn:idea:25>, and immediately after adding it I execute DROP GRAPH <urn:idea:25>, again ALL the named graphs are removed and context set gets totally empty.

Everything was executed over RD4J REST /statements endpoint for SPARQL UPDATE protocol. Repository is Native Store + RDFS and SPIN.

This is a serious and critical bug, in v2.5.3. and v3 Please try to analyse it and to provide a bugfix or explanation/workaround for it.

Please respond to this issue ASAP. Thanks in advance.

@barthanssens barthanssens added the bug label Sep 19, 2019
@barthanssens barthanssens added this to the 3.0.1 milestone Sep 19, 2019
@barthanssens

This comment has been minimized.

Copy link
Contributor

@barthanssens barthanssens commented Sep 19, 2019

Thanks for the detailed bug report, we'll look into it

@barthanssens

This comment has been minimized.

Copy link
Contributor

@barthanssens barthanssens commented Sep 19, 2019

Seems to be an issue deeper in the library (using 3.0, ode listed below also removes all data)

public class Main {
	private final static String INS_1 = 
		"INSERT DATA { GRAPH <urn:idea:1>  { <http://ex.com/1/s> <http://ex.com/1/p> <http://ex.com/1/o> } }";
	private final static String INS_2 = 
		"INSERT DATA { GRAPH <urn:idea:2>  { <http://ex.com/2/s> <http://ex.com/2/p> <http://ex.com/2/o> } }";

	private final static String DROP_1 = 
		"DROP GRAPH <urn:idea:1>";
		
	private final static String DROP_100 = 
		"DROP GRAPH <urn:idea:100>";
	
	public static void main(String[] args) {
		File temp = Paths.get(".").toFile();
		Repository db = new SailRepository(new NativeStore(temp));
		
		System.err.println("Initialized");
		
		try(RepositoryConnection conn = db.getConnection()) {
			conn.clear();

			Update u1 = conn.prepareUpdate(INS_1);
			u1.execute();
			Update u2 = conn.prepareUpdate(INS_2);
			u2.execute();
			
			RepositoryResult<Statement> res = conn.getStatements(null, null, null);
			while (res.hasNext()) {
				System.err.println(res.next());
			}
			System.err.println(conn.size());
		}
		
		System.err.println("Before drop");
		
		try(RepositoryConnection conn = db.getConnection()) {
			Update d100 = conn.prepareUpdate(DROP_100);
			d100.execute();
			
			RepositoryResult<Statement> res = conn.getStatements(null, null, null);
			while (res.hasNext()) {
				System.err.println(res.next());
			}
			System.err.println(conn.size());
		}
				
		System.err.println("End");
		
		db.shutDown();
	}
}
@barthanssens

This comment has been minimized.

Copy link
Contributor

@barthanssens barthanssens commented Sep 19, 2019

Seems to be a specific problem in NativeStore, and low-level (code below also incorrectly removes all data in NativeStore, but behaves correctly in MemoryStore)

try(RepositoryConnection conn = db.getConnection()) {
	IRI urn1= conn.getValueFactory().createIRI("urn:idea:100");
	conn.remove((Resource) null, null, null, urn1);
	RepositoryResult<Statement> res = conn.getStatements(null, null, null);
	while (res.hasNext()) {
		System.err.println(res.next());
	}
	System.err.println(conn.size());
}
@barthanssens

This comment has been minimized.

Copy link
Contributor

@barthanssens barthanssens commented Sep 20, 2019

I think it's because NativeSailStore.removeStatements seems to treat an unknown context the same as no context (+/- line 528 valueStore.getID)

@jeenbroekstra

This comment has been minimized.

Copy link
Contributor

@jeenbroekstra jeenbroekstra commented Sep 24, 2019

Looks like a regression introduced by #1453

barthanssens added a commit that referenced this issue Sep 24, 2019
make invalid context different from unknown/all context + added test
@barthanssens

This comment has been minimized.

Copy link
Contributor

@barthanssens barthanssens commented Sep 24, 2019

@jeenbroekstra : just wondering, is 2.5.x bugfix release still possible with the new single-repo setup ? or would this be a 3.0.x-only fix ?

@jeenbroekstra

This comment has been minimized.

Copy link
Contributor

@jeenbroekstra jeenbroekstra commented Sep 25, 2019

@barthanssens it's possible but some extra work. We would need to run it using the three repos (so we'd need to manually copy this fix over to rdf4j-storage), and we'd need to reenable some Jenkins jobs to deploy.

Just doing a 3.0.1 is a lot simpler but I guess this bug is serious enough that we really should do a backport.

@jeenbroekstra

This comment has been minimized.

Copy link
Contributor

@jeenbroekstra jeenbroekstra commented Oct 6, 2019

@barthanssens is this bug considered fixed? If so we can close it, and do a patch release this week.

@jeenbroekstra jeenbroekstra modified the milestones: 3.0.1, 3.1.0 Oct 6, 2019
@barthanssens

This comment has been minimized.

Copy link
Contributor

@barthanssens barthanssens commented Oct 6, 2019

Yes, it's solved

Next release automation moved this from To do to Done Oct 6, 2019
@jeenbroekstra jeenbroekstra changed the title Major bug with DROP GRAPH <non-existing-graph-in-repo>executed over /statements Sparql Update protocol DROP GRAPH <non-existing-graph-in-repo> deletes entire dataset on native store Oct 13, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Next release
  
Done
3 participants
You can’t perform that action at this time.