Hi Tim,
On 11 November 2013 18:09, Tim Donohue <tdono...@duraspace.org> wrote:
> Actually, this is a big deal, as whether an ID in the REST API was
> persistent would now *depend* how you are backing up your DSpace
>
Well, it depends on the guarantees that you want to provide. If you are
expecting to manually enter an ID into a CMS to pull data into a page, then
you need some persistence. If you are discovering the IDs, less important.
> Some folks still do backups of the database & files separately -- as
> noted, this would retain database IDs.
>
> However, others are using the AIP Backup & Restore tools for backup
> (namely to services like DuraCloud or similar, or for some of the other
> benefits of AIPs, e.g. single object restoration). AIPs WILL NOT retain
> database IDs when recovering content. So, a simple recovery would cause
> your Database ID to change. They will however retain global identifiers
> like Handles.
It could be argued (and I possibly would) that this is a problem in the
design of AIP - it would be possible to store the internal ID, and take all
reasonable steps to restore it, but not guarantee it.
This would allow it to differ if migrating to a different instance, but
restoring a (full) backup would restore that internal ID.
Ideally, I would like to see a primary object URL using an
>> instance-persistent public ID - which is not the handle or DOI - and
>> that would be the primary ID that you use in the REST API. But, on top
>> of that, if you configure a real persistent identifier, you could get to
>> the object - both in the UI and the API, using that identifier.
>>
>
> Oh yes, I totally agree with this. I'd rather have DSpace assign its own
> instance-unique PIDs. I'd just argue that a Database ID cannot be that PID,
> as it's an auto-incrementing sequence (and hard to "reuse" in cases of
> restoring/recovering deleted content, which is why AIPs have a hard time
> retaining Database IDs)
However, the suffix on a handle is also an auto-incrementing sequence. It
doesn't gain magical properties just by having a prefix attached!
Whilst correctly registered, unique prefixes have some benefit for
migrating / merging DSpace content, we don't actually have any guarantee of
correctly registered prefixes, and therefore don't have any guarantee of
avoiding collisions.
And for restoring/recovering deleted content [in the instance it was
created in/replacement for it], then there is nothing that the handle gives
you over the database ID - it is the same prefix, with an auto-incremented
distinct component.
The only reason why we can restore the handle and not the database ID
(aside from it not being part of the AIP), is because we don't expose a
means of manually setting the primary key in the DatabaseManager. There is
no reason why we couldn't - despite being sequence based, we select the
next value and assign it as part of the insert statement, it's not forced
on us by the database.
As I said, we put too much stock in persistent identifiers. More to the
point, we make too many assumptions about what handles mean, when our
implementation doesn't - and really can't - provide those guarantees.
As soon as we accept that, and take the necessary steps to make our best
effort to deal with them, including handling collisions, then there is no
reason why we can't apply exactly the same handling to database IDs.
Because they are effectively the same thing in the way they are generated.
G
------------------------------------------------------------------------------
DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
