search

antoniogarrote / rdfstore-js

JS RDF store with SPARQL support
MIT License
564 stars 109 forks source link

SPARQL DELETE does not delete everything #63

Open mainini opened 10 years ago

mainini commented 10 years ago

Given the dataset in the following turtle snippet:

https://gist.github.com/castanea/8009815

When running the following DELETE-queries:

DELETE WHERE { GRAPH <http://webidp.local/idp> {  <http://webidp.local/certs#2111edf479941934cb7b0fd437eea5e207901ae7> ?p ?o . } }
DELETE WHERE { GRAPH <http://webidp.local/idp> { <http://webidp.local/webids/test/a7937b64b8caa58f03721bb6bacf5c78cb235febe0e70b1b84cd99541461a08e> ?p ?o . } }
DELETE WHERE { GRAPH <http://webidp.local/idp> {  ?user <http://webidp.local/vocab#webID> <http://webidp.local/webids/test/a7937b64b8caa58f03721bb6bacf5c78cb235febe0e70b1b84cd99541461a08e> . } }

Not all the data expected gets deleted, the following triple remains in store:

<http://webidp.local/certs#2111edf479941934cb7b0fd437eea5e207901ae7> <http://webidp.local/vocab#base64DER> "MIIEYzCCA0ugAwIBAgIUIRHt9HmUGTTLew/UN+6l4geQGucwDQYJKoZIhvcNAQELBQAwgYQxLTArBgNVBAoTJEJlcm5lIFVuaXZlcnNpdHkgb2YgQXBwbGllZCBTY2llbmNlczEvMC0GA1UECxMmRW5naW5lZXJpbmcgYW5kIEluZm9ybWF0aW9uIFRlY2hub2xvZ3kxCzAJBgNVBAYTAkNIMRUwEwYDVQQDEwxCRkggV2ViSUQgQ0EwHhcNMTMxMjAyMTM0ODMzWhcNMTQxMjAyMTM0ODMzWjBUMRYwFAYDVQQDEw1KdXN0dXMgVGVzdHVzMQswCQYDVQQGEwJDSDEtMCsGA1UEChMkQmVybmUgVW5pdmVyc2l0eSBvZiBBcHBsaWVkIFNjaWVuY2VzMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3S/I/LvgOlMHEGi4NL1xpcEdLx0YH7zxMCtN+Fl6re6eYdXd/b5iOmCnjr0WC1Mg6KfEOWwMtila4zx3akn9DcFd53aULDVcfG4vpSogxeJJtWbzTuzqtU3R8DWeRaZf3+TpgWY/tZrYdiuNVoTAbV0EytOtiKZuMRzkaOXPhUjtcc+4nlsuQjEvC3OxEEzhFyNVDznP9TkcAglPwnuhYeaQZrBwaobDm7GyajB3K6mZzyK5brHK6e20yFBSNFWK9mjrp7nIGHHgcPP9+TzfOuY+3XrNY2rBFYHkXZxN0aK0Cppq80f0ZRmzPfasbeh65xiFy5IMDlXCNINo8LN8wQIDAQABo4H7MIH4MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDCBjAYDVR0RAQH/BIGBMH+GZ2h0dHBzOi8vbG9jYWxob3N0Ojg0NDMvaWQvdGVzdC9hNzkzN2I2NGI4Y2FhNThmMDM3MjFiYjZiYWNmNWM3OGNiMjM1ZmViZTBlNzBiMWI4NGNkOTk1NDE0NjFhMDhlI3Byb2ZpbGWBFGp1c3R1cy50ZXN0dXNAYmZoLmNoMBEGCWCGSAGG+EIBAQQEAwIHgDAdBgNVHQ4EFgQUlfYRktGPiLrfuMHbLWYXq6RVx7QwDQYJKoZIhvcNAQELBQADggEBAFEkViztWGOAQHdMKoMfSIQYN0Mpyhpzh2zD0dkwHIRH0J1KC3mWHgp4T5e5VW9HSbxI/ROfp4FFIjcLszL8vSQjMSwjyt7P9Ca0fNRLlaCDIswZjjAxGxAyd8PqYspRpQYdSpneYJF0PC/CkyNbWII0QxjsjtDBUCvZqZK965OFpq2sCvo3aa0vOmhdjYjHSFVWdSXf4RSb61bL14sYzb0TT2kMdVNibsRszcRCiCRfH1Jk5pj2MqShV2+7OXzC2YKAuJmbrhOCmOE06FaRBJbZU9TpoBWvEEOJGl7SI4n7VBBlRr8CjS2uANFlj1J8Gs5UYxXDaf6fV4pgQxASspw="^^<http://www.w3.org/2001/XMLSchema#base64Binary> .

Besides this one, three other triples remain, which is correct and on purpose.

I verified the behaviour several times with different datasets (looking the same in terms of lengths etc.) and think that it is related to the size of the subject of the triple in question. Same behaviour seems to occur when not specifiying the type base64Binary for it.

Additionally, I ran a test using Fuseki with the exact same data and get the expected result (the triple given above beeing deleted as well).