tombstone resource

[Adam Wead]

Hi all,

I’m getting:

STATUS: 410 Discovered tombstone resource at org.fcrepo.kernel.impl.TombstoneImpl@9ca470a…

This is with ActiveFedora… we delete http://localhost/rest/test before each test so the repo’s empty. I’m guessing the latest changes in Fedora delete things without removing them. How do I *really* delete them? ActiveFedora is using Chris’s LDP::Client to call .delete.

…adam

[Andrew Woods]

Hello Adam,

As you observed, F4 creates a tombstone when a resource is deleted. Among other things, this is driven by the LDP requirements not to reuse URIs:

http://www.w3.org/TR/ldp/

=========

5.2.3.11 LDP servers that allow member creation via POST should not re-use URIs.

6.1.2 LDP servers should not re-use URIs, regardless of the mechanism by which members are created (POST, PUT, etc.). Certain specific cases exist where a LDPC server might delete a resource and then later re-use the URI when it identifies the same resource, but only when consistent with Web architecture. While it is difficult to provide absolute implementation guarantees of non-reuse in all failure scenarios, re-using URIs creates ambiguities for clients that are best avoided.

=========

If however, you do indeed really want to reuse the URIs of deleted resources, you can remove the tombstone with:
curl -X DELETE http://localhost:8080/rest/some/deleted/node/fcr:tombstone

The REST-API documentation has been recently updated (thanks Chris!).

https://wiki.duraspace.org/display/FF/RESTful+HTTP+API#RESTfulHTTPAPI-RedDELETEDeletearesource

Andrew

On Tue, Oct 21, 2014 at 9:45 PM, Adam Wead <amste...@gmail.com> wrote:

Hi all,

I'm getting:

STATUS: 410 Discovered tombstone resource at org.fcrepo.kernel.impl.TombstoneImpl@9ca470a...

This is with ActiveFedora... we delete http://localhost/rest/test before each test so the repo's empty.  I'm guessing the latest changes in Fedora delete things without removing them.  How do I *really* delete them?  ActiveFedora is using Chris's LDP::Client to call .delete.

...adam

--
You received this message because you are subscribed to the Google Groups "Fedora Tech" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fedora-tech...@googlegroups.com.
To post to this group, send email to fedor...@googlegroups.com.
Visit this group at http://groups.google.com/group/fedora-tech.
For more options, visit https://groups.google.com/d/optout.

[Chris Beer]

That said, please don’t just remove it at …/fcr:tombstone. There’s an HTTP Link header from the 410 Gone response to the tombstone resource. Use that link to discover where the tombstone resource is.

Chris

[Adam Wead]

So intercept the exception raised by LDP?  BTW, this is really a testing problems because we need to delete all the F4 resources before and after each test.  An actual implementation using tombstones in ActiveFedora is still TBD.

…adam

[Esmé Cowles]

Adam-

Before you get the LDP exception -- when the initial delete happens (and succeeds) it should get a response with a Link header pointing to the tombstone. I think Chris is just saying you should use the Link header instead of just assuming the it's .../fcr:tombstone (since that could change or be different on a different system).

-Esme

[Adam Wead]

Oh I see. thanks,

…adam

On Oct 22, 2014, at 11:23, Esmé Cowles <esco...@ticklefish.org> wrote:

> Adam-
>
> Before you get the LDP exception -- when the initial delete happens (and succeeds) it should get a response with a Link header pointing to the tombstone. I think Chris is just saying you should use the Link header instead of just assuming the it's .../fcr:tombstone (since that could change or be different on a different system).
>
> -Esme
>
>> On Oct 22, 2014, at 11:17 AM, Adam Wead <amste...@gmail.com> wrote:
>>
>> So intercept the exception raised by LDP? BTW, this is really a testing problems because we need to delete all the F4 resources before and after each test. An actual implementation using tombstones in ActiveFedora is still TBD.
>>

>> ...adam

>>
>>
>> On Oct 22, 2014, at 10:50, Chris Beer <ch...@cbeer.info> wrote:
>>

>>> That said, please don't just remove it at .../fcr:tombstone. There's an HTTP Link header from the 410 Gone response to the tombstone resource. Use that link to discover where the tombstone resource is.

[Adam Wead]

On second look, no, I don’t. I’m using LDP::Client to call delete and I get back a Faraday::Response object the looks something like this:

#<Faraday::Response:0x007f8bec255c90 @on_complete_callbacks=[], @env=#<Faraday::Env @method=:delete @body="" @url=#<URI::HTTP:0x007f8bec25ce78 URL:http://localhost:8983/fedora/rest/test> @request=#<Faraday::RequestOptions (empty)> @request_headers={"User-Agent"=>"Faraday v0.9.0"} @ssl=#<Faraday::SSLOptions (empty)> @response_headers={"connection"=>"close"} @status=204>>

Which doesn’t have anything in it regarding a tombstone, that I can see at least...

Any further calls to the resource, after it’s been deleted, result in a 410 error.

…adam

[Esmé Cowles]

Adam-

I'm sorry -- the Link header is actually in the 410 Gone response:

GET http://localhost:8080/rest/abc123

HTTP/1.1 410 Gone
Content-Length: 78
Link: <http://localhost:8080/rest/abc123/fcr:tombstone>; rel="hasTombstone"

That Link header points to the tombstone that needs to be deleted.

-Esme

> On Oct 22, 2014, at 3:41 PM, Adam Wead <amste...@gmail.com> wrote:
>
> On second look, no, I don't. I'm using LDP::Client to call delete and I get back a Faraday::Response object the looks something like this:
>
> #<Faraday::Response:0x007f8bec255c90 @on_complete_callbacks=[], @env=#<Faraday::Env @method=:delete @body="" @url=#<URI::HTTP:0x007f8bec25ce78 URL:http://localhost:8983/fedora/rest/test> @request=#<Faraday::RequestOptions (empty)> @request_headers={"User-Agent"=>"Faraday v0.9.0"} @ssl=#<Faraday::SSLOptions (empty)> @response_headers={"connection"=>"close"} @status=204>>
>
> Which doesn't have anything in it regarding a tombstone, that I can see at least...
>
> Any further calls to the resource, after it's been deleted, result in a 410 error.
>

> ...adam
>
>

> On Oct 22, 2014, at 11:24, Adam Wead <amste...@gmail.com> wrote:
>
>> Oh I see. thanks,
>>

[A. Soroka]

Or, as Chris (I think rightly) wrote: _not_ deleted.

---
A. Soroka
The University of Virginia Library

[Adam Wead]

ah, okay. Then should I patch LDP::Client? It’s interpreting that as an error and raising an exception.

…adam

[Esmé Cowles]

Adam-

I understood Chris to be saying not to just append /fcr:tombstone to the end of the URI -- to use the Link header to figure out where the tombstone is, not to be saying that the tombstone shouldn't be deleted at all.

IMHO, the LDP spec guidance on not re-using URIs isn't really applicable in this context (ephemeral resources created by tests).

-Esme

[Esmé Cowles]

Adam-

Well, in real production use, it would be an error, so I think the error should be the default behavior. But there should definitely be a way to override it and force delete the tombstone.

-Esme

> On Oct 22, 2014, at 3:53 PM, Adam Wead <amste...@gmail.com> wrote:
>
> ah, okay. Then should I patch LDP::Client? It's interpreting that as an error and raising an exception.
>

[aj...@virginia.edu]

Agreed-- I was thinking more of the default behavior of the client with which Adam is concerned. That behavior, I think, should _not_ be to delete the tombstone.

---
A. Soroka
The University of Virginia Library

[Adam Wead]

Right. In fact, ActiveFedora may just raise an exception when it encounters a tombstone and thereby preventing the re-useage of URIs. That’s probably the way it will end up. However, for testing purposes where we need to stand up a new repository for each test, I’m just going to tack on /fcr:tombstone and couch it in a rescue block because it works. Other suggestions are welcome, however :)

…adam