[
https://jira.duraspace.org/browse/DS-712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17840#action_17840
]
Richard Rodgers commented on DS-712:
------------------------------------
I'm not sure I'd call this a blocker - admittedly the assignment algorithm is
fragile in the sense you describe, but the whole notion of 'migrating' one
DSpace into another is not really well defined to begin with.
In normal restoration cases (restoring from AIPs that originally belonged to
the same repository) we should avoid this because we are reinserting values
into a previously allocated sequence. I'd be *very*
leery of introducing inefficient scans of the handle table to cover this case:
have everyone pay the tax for situations that won't occur. I agree that in
time, we should improve the algorithm, but not as a quick fix for 1.7. Just my
2 cents
> 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
