Items 11/4/2015 were givent the incorrect handle prefix, 123456789/

[alawvt]

Yesterday, the commits from the Bichon Frase sprints were pushed to production. The customization in dspace.cfg for our handle was omitted so it was left to the incorrect default, 123456789/. I have started to identify items that were assigned that handle. One is http://vtechworks.lib.vt.edu/handle/123456789/63904?show=full. @kayiwa, would it be possible for you to give us a list of items that were loaded yesterday and/or have the 123456789/ handle? @keithgee or @kayiwa, do you know if it is possible to give an existing item a new handle?

[alawvt]

Using a search for "123456789", I found these handles: vtechworks.lib.vt.edu/handle/123456789/63900 can't be found. vtechworks.lib.vt.edu/handle/123456789/63901 can't be found. vtechworks.lib.vt.edu/handle/123456789/63902 can't be found. http://vtechworks.lib.vt.edu/handle/123456789/63903 - I have already deleted this ETD and will upload it tomorrow. http://vtechworks.lib.vt.edu/handle/123456789/63904 - item in BioMed Central collection. http://vtechworks.lib.vt.edu/handle/123456789/63905 - item in BioMed Central collection. http://vtechworks.lib.vt.edu/handle/123456789/63906 - item in BioMed Central collection. http://vtechworks.lib.vt.edu/handle/123456789/63907 is the Center for Peace Studies and Violence Prevention community. http://vtechworks.lib.vt.edu/handle/123456789/63908 is the Instructional Materials, University Libraries collection. vtechworks.lib.vt.edu/handle/123456789/63909 can't be found. vtechworks.lib.vt.edu/handle/123456789/63910 can't be found.

So it looks like we need to deal with 904, 905, 906, 907, and 908.

[kayiwa]

Is the -r flag it?

Discovery Solr Index Maintenance
Command used:
[dspace]/bin/dspace index-discovery [-cbhf[r <item handle>]]
Java class:
org.dspace.discovery.IndexClient
Arguments (short and long forms):
Description

called without any options, will update/clean an existing index
-b
(re)build index, wiping out current one if it exists
-c
clean existing index removing any documents that no longer exist in the db
-f
if updating existing index, force each handle to be reindexed even if up to date
-h
print this help message
-o
optimize search core
-r <item handle>
remove an Item, Collection or Community from index based on its handle
-s  Rebuild the spellchecker, can be combined with -b and -f.

From the duraspace documentation.

[alawvt]

I don't think removing the items from the index would help at the moment. Perhaps later.

[kayiwa]

I would remove and reindex. Wouldn't that solve the problem?

[alawvt]

That would remove items from the search index. But we need to find them and give them new handles either by assigning them new handles or resubmitting them.

[mello99]

Hi there, I deleted both the "Instructional Materials, University Libraries" collection and the "Center for Peace Studies and Violence Prevention" community, then re-created them both. I still ended up with funky handles - http://vtechworks.lib.vt.edu/handle/123456789/63907 for the "Center for Peace Studies and Violence Prevention", and http://vtechworks.lib.vt.edu/handle/123456789/63910 for "Instructional Materials, University Libraries." I've since deleted both since neither community/collection contained any items. Nonetheless, the handle issue has not been solved.

[kayiwa]

hey guys. This is a dspace problem... admittedly caused by a borked configuration. Someone (not going to be me I'm afraid) will need to figure out how to remove the wrongly assigned handles and reindex them.

[alawvt]

@kayiwa restarted Tomcat and now the handles of new items are correct.

[mello99]

Hi all, I deleted the 3 problematic BioMed Central items and re-uploaded them using the "Import Metadata" tool. Their new handles are the following:

http://hdl.handle.net/10919/63915 http://hdl.handle.net/10919/63916 http://hdl.handle.net/10919/63917

I also recreated the "Center for Peace Studies and Violence Prevention" community (http://vtechworks.lib.vt.edu/handle/10919/63913), and the "Instructional Materials, University Libraries" collection (http://vtechworks.lib.vt.edu/handle/10919/63914). I'm going to close this issue since it appears to have been resolved. Thanks everyone!

[keithgee]

Great work! This sort of thing happens from time to time, and there's even a /dspace/bin/dspace update-handle-prefix 123456789 10919 spell to help with cleanup.

Also, at the time the aardvark sprint was released to production, I'd merged all of the changes back into the dspace_5_x branch and then tagged it as a release. Should we do this with Bichon Frise as well? I think we're deploying directly from the dev branch, but I suppose that makes sense if that's what we're testing. I like having some sort of tag, though, to be able to see just what's in production at a given time, and also to rollback to a previous release, if, heaven forbid, we ever have problems that are tough to resolve quickly.

Thoughts?

[alawvt]

@keithgee, thank you for the information about the update-handle-prefix utility. That will make things easier in the future.

I agree: I would like to have commits that in production be on the dspace_5_x branch.