Hi All,

It's actually not a bug to leave behind the handle record after the 
object is deleted. It's actually a *feature* of the AIP Backup & Restore 
functionality...here's why:

1. Handles need to be persistent (at least persistent enough that we 
know whether they've previously been assigned to an object)

2. If that object is deleted, we need some retained record that its 
handle was once used for an ITEM, COLLECTION, COMMUNITY (or whatever 
type of object)

3. If later on, you wish to restore that deleted object (via AIP 
Restoration), we attempt to also restore it's pre-existing handle. 
However, we also do a basic check to ensure it's the same *type* of 
object. In other words, we won't let you restore a COLLECTION and assign 
a handle that used to apply to an ITEM.

In other words, we don't want you to just start re-using Handles that 
used to exist -- we need some basic record of what handles were created 
already.

Ideally, we'd also keep around some record of the deleted Item itself 
(so we could do a more thorough check during restoration). However, 
currently the best we can do is keep around info on the *type* of object 
that used to exist at that Handle.

If this feature were removed, in my opinion, it'd actually be 
detrimental to the AIP Backup & Restore feature (as the trustworthiness 
of handle restoration would decrease).

- Tim

On 5/4/2012 4:56 PM, Mark Diggory wrote:
> I don't think anything material can be truly immortal.  With Handles,
> theres an attempt to be persistent, but the whole Handle resolution
> framework has no means to guarantee that a handle is going to be
> resolved nor any information retainable concerning what it pointed at.
>   At least with DSpace's current implementation.  Thats part of the
> "misconception", take down your handle server, and no one can resolve
> anything about your minted handles any longer.  Not even to identify the
> URL they were originally pointing at.  Add onto this, that deleting an
> Item results in no record of that Item existing any longer in DSpace
> (outside of dspace.log). That doesn't sound like persistence to me, if
> your lucky some detail about the item internal id is still mapped to the
> handle in the logs.
>
> Mark
>
> On Fri, May 4, 2012 at 2:42 PM, Mark H. Wood <[email protected]
> <mailto:[email protected]>> wrote:
>
>     I'm not so sure that it is a bug to leave the handle record behind
>     when deleting an object.  Shouldn't Handles be immortal, since they
>     are meant to be forever unique?  At the very least it is a form of
>     protection against somehow reissuing that Handle.
>
>     Probably it is about time to refresh our thinking on what it should
>     mean to delete an object from a repository.
>
>     --
>     Mark H. Wood, Lead System Programmer   [email protected]
>     "640KB should be enough for anyone."
>
>     
> ------------------------------------------------------------------------------
>     Live Security Virtual Conference
>     Exclusive live event will cover all the ways today's security and
>     threat landscape has changed and how IT managers can respond.
>     Discussions
>     will include endpoint security, mobile security and the latest in
>     malware
>     threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>     _______________________________________________
>     Dspace-devel mailing list
>     [email protected]
>     <mailto:[email protected]>
>     https://lists.sourceforge.net/lists/listinfo/dspace-devel
>
>
>
>
> --
> @mire Inc.
>       *Mark Diggory *(Schedule a Meeting <https://tungle.me/markdiggory>)
> /2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010/
> /Esperantolaan 4, Heverlee 3001, Belgium/
> http://www.atmire.com <http://www.atmire.com/>
>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
>
> _______________________________________________
> Dspace-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/dspace-devel

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel

Reply via email to