Hi Andy Ok good to know about the 204 being a valid success code
As far as I was aware this isn't the default graph. I am doing a PUT to a specific Graph URI so surely I should be able to DELETE it at that specific URI as well? For the record I am only putting one Graph in there so is it being treated as the default graph since it is the only Graph? What does Fuseki count as being the default graph? It would be helpful if the Fuseki documentation was expanded somewhat to cover points like this. > The default graph can't be deleted. It always exists so DELETE (which > is DROP in SPARQL Update) => CLEAR Yes I had already implemented the above in my own implementations of the standards due to how my API handles the default graph internally. The empty vs non-existent Graph distinction is not really an issue in this case. In the unit test I am checking to see that either I get an exception (which would indicate a non 2xx response from the server) or that the returned Graph is empty. Rob -----Original Message----- From: Andy Seaborne [mailto:[email protected]] Sent: 27 January 2011 18:55 To: [email protected] Subject: Re: Fuseki DELETE doesn't seem to work On 27/01/11 09:33, Rob Vesse wrote: > > > Hi all > > I've coded up some simple unit tests to test the Fuseki support > in my library and noticed that HTTP DELETE does not seem to work. > > I use > PUT in my code to add a Graph and can see it via the /data endpoint of > Fuseki > > I use GET in my code to retrieve the Graph to check it is stored > correctly which it is > > I then try and use DELETE to remove the Graph but I > get a 204 No Content response - according to the Uniform HTTP Protocol spec > I should get a 200/202 to indicate success. 204 (anything 2xx) is success. In fact the spec now says (working draft): [[ A response code of 200 (OK) or 204 (No Content) SHOULD be given in the response ]] > But if I subsequently do a GET > then the Graph is still present in the dataset so DELETE has apparently not > worked. > > Is this a bug or related to my dataset. I am using the default > in-memory dataset and running Fuseki using the following command: > The default graph can't be deleted. It always exists so DELETE (which is DROP in SPARQL Update) => CLEAR The spec should say this - I'll email the WG. I tried: s-put http://localhost:3030/ds http://example/g D.nt s-get http://localhost:3030/ds http://example/g s-delete http://localhost:3030/ds http://example/g s-get http://localhost:3030/ds http://example/g and get a 404 for the second s-get. If I replace http://example/g with default, I get an empty graph at the second s-get. Andy BTW, there is going to be variations in the treatment of empty graphs between systems - does and empty graph exist? That's tricky as some stores store graphs and some store quads. A pure quads view can't tell empty from non-existent. > java > -jar fuseki-0.1.0-server.jar --update --mem /dataset > > The log trace looks > this: > > 09:30:30 INFO Fuseki :: Dataset: in-memory > 09:30:30 INFO Fuseki :: > Update enabled > 09:30:30 INFO Fuseki :: Fuseki 0.1.0 > 09:30:30 INFO Fuseki :: > Jetty 7.x.y-SNAPSHOT > 09:30:30 INFO Fuseki :: Dataset = /dataset > 09:30:30 > INFO Fuseki :: Started 2011/01/27 09:30:30 GMT on port 3030 > 09:30:35 INFO > Fuseki :: [1] PUT > http://localhost:3030/dataset/data?graph=http%3A%2F%2Fexample.org%2FfusekiTest > 09:30:35 > INFO Fuseki :: [1] 201 Created > 09:30:35 INFO Fuseki :: [2] DELETE > http://localhost:3030/dataset/data?graph=http%3A%2F%2Fexample.org%2FfusekiTest > 09:30:35 > INFO Fuseki :: [2] 204 No Content > > By the way is there a reason that GET > requests aren't in the log trace? I notice that if I do a SPARQL Query to > the /query endpoint it appears in the trace so why not a GET to the /data > endpoint? > > I can provide code if desired but the code is all in C# so not > necessarily very helpful to you for debugging purposes. If you need further > information to investigate this please let me know. > > Rob Vesse
