[
https://jira.duraspace.org/browse/DS-712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17842#action_17842
]
Tim Donohue commented on DS-712:
--------------------------------
Neglected to mention -- I do agree with your point about avoiding something
that will cause everyone to pay a tax for a situation which may not affect
them. There may be another way to provide a script to auto-bump up the
'handle_seq' value whenever you do a full restore. Still digging around at
options -- suggestions welcome.
> 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
