[
https://jira.duraspace.org/browse/DS-712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17845#action_17845
]
Tim Donohue commented on DS-712:
--------------------------------
The restore of the AIPs themselves actually isn't an issue -- so, there's no
need to actually worry about what 'handle_seq' is set to *before* a restore
happens. The problematic part is *after* the restore happens -- which is where
you'd just want to update handle_seq to the current highest assigned handle
(with your currently configured handle prefix) in the DB. Looking into that
update query now -- just would be easier to implement across Postgres & Oracle
if we were not storing the handle as a string :)
> DSpace Fails to Check if a Handle is already assigned before assigning a new
> handle
> -----------------------------------------------------------------------------------
>
> Key: DS-712
> URL: https://jira.duraspace.org/browse/DS-712
> Project: DSpace
> Issue Type: Bug
> Components: DSpace API
> Affects Versions: 1.7.0
> Reporter: Tim Donohue
> Assignee: Tim Donohue
> Priority: Blocker
> Fix For: 1.7.0
>
>
> Not sure how this hasn't come up before, but I just noticed this in terms of
> testing the new AIP Backup/Restore functionality (DS-466).
> DSpace currently makes a highly flawed assumption when assigning new Handles.
> It will *always* assign a Handle equal to the next available value in the
> 'handle_seq' (which is just the max value of 'handle_id' in the 'handle'
> table). See the HandleManager.createHandle() method.
> This becomes extremely fragile when you have content which has been migrated
> or restored from another DSpace (for example, via the AIP backup/restore
> feature). In those instances, it you may end up restoring/migrating content
> that looks like this:
> handle_id = 44 (or whatever the next value in 'handle_seq' is)
> handle = 123456789/50 (or whatever the restored handle should be)
> Once the value of 'handle_id' reaches the suffix value of a restored handle,
> then you will run into database conflicts & will be unable to submit any new
> content into DSpace. So, in the above example, as soon as 'handle_seq" gets
> to the value of 50, Dspace will attempt to assign a new handle of
> '123456789/50' to the next object created. However, as that handle is
> already in use, the new object will always fail to be created. In other
> words, the DSpace system will fail to accept any new objects.
> The fix would be to first ensure a handle is *not* already in use before
> assigning it -- essentially looking for the next available handle (rather
> than the next value of 'handle_seq") before assigning the handle. However, I
> need to determine a reasonable way to locate the next available handle
> (preferably something that will scale relatively well for larger installs).
> Ideas / thoughts / brainstorms welcome. I've marked this as a "Blocker" for
> DSpace 1.7.0, as it essentially makes your DSpace unusable if you were to
> encounter this bug. (The only way to get around this issue if you
> encountered it is to manually increase your "handle_seq" so that it's greater
> than the largest handle suffix in your system.)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.duraspace.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
