Hi Tim
Check this: http://scholar.sun.ac.za/handle/10019.1/4191
It gets worse when you move from one handle to another.
This is one of the reasons I wrote up:
http://scholar.sun.ac.za/handle/10019.1/3161
There is no reliance on a "URL resolving authority" only a UUID, real
simple.
Cheers
hg
On 21/10/2010 20:03, Tim Donohue (DuraSpace JIRA) wrote:
[
https://jira.duraspace.org/browse/DS-712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Donohue updated DS-712:
---------------------------
Status: Open (was: Received)
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.)
--
Hilton Gibson
Systems Administrator
JS Gericke Library
Room 1053
Stellenbosch University
Private Bag X5036
Stellenbosch
7599
South Africa
Tel: +27 21 808 4100 | Cell: +27 84 646 4758
"Simplicity is the ultimate sophistication"
Leonardo da Vinci
------------------------------------------------------------------------------
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
