Hi all, I finally got around to trying this out on our dev server: updated the “handle” table to point two different handles to the one resource_id (and none to the withdrawn resource_id). It seemed in the first instance to work – following the links did what I expected.
Then I tried running the index-discovery -b job. That kept stopping mysteriously in the middle of it – no obvious errors in the solr or dspace logs, just stopped. (I don’t know, maybe our dev server’s just slow and ran out of memory or got distracted or something.) But running index-discovery with no options picked up where it left off, and after a couple of repetitions of this it finally indexed the item in question and all my search/browse tests worked as expected too. So I was on the verge of declaring victory – and then I ran an oai import -c -v job. To my tremendous disappointment that failed partway through with: Item with handle null indexed org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException: Document is missing mandatory uniqueKey field: item.handle at org.apache.solr.client.solrj.impl.HttpSolrServer.executeMethod(HttpSolrServer.java:552) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:210) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:206) at org.apache.solr.client.solrj.request.AbstractUpdateRequest.process(AbstractUpdateRequest.java:124) at org.apache.solr.client.solrj.SolrServer.add(SolrServer.java:116) at org.apache.solr.client.solrj.SolrServer.add(SolrServer.java:102) at org.dspace.xoai.app.XOAI.index(XOAI.java:213) at org.dspace.xoai.app.XOAI.indexAll(XOAI.java:200) at org.dspace.xoai.app.XOAI.index(XOAI.java:131) at org.dspace.xoai.app.XOAI.main(XOAI.java:495) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.dspace.app.launcher.ScriptLauncher.runOneCommand(ScriptLauncher.java:226) at org.dspace.app.launcher.ScriptLauncher.main(ScriptLauncher.java:78) This makes sense in retrospect: the OAI feed includes withdrawn items (in order to publish a “record status: deleted” record) but identifies them by their handles (so obviously requires a handle). This is highly disappointing, but at least now we know. It looks like it would work for a repository which didn’t publish an OAI feed, but sadly that’s vital for us. Our fall-back will be to follow Claudia’s suggestion of adjusting the Item Withdrawn page and using the metadata to point to the new item. Deborah From: Tim Donohue <tdono...@duraspace.org> Sent: Friday, 15 June 2018 2:42 AM To: Fitchett, Deborah <deborah.fitch...@lincoln.ac.nz> Cc: dspace-tech@googlegroups.com Subject: Re: [dspace-tech] handles, isreplacedby, and withdrawn items Hi Deborah, I'll admit, I've never tried this myself, but your suggestion to simply update the old "handle" table entries to point at the new "resource_id" seems like it *should work*. The "handle" table in DSpace is really just used to resolve/assign Handles to Objects. So, at least conceptually, it should support pointing two handles at the same object (Item). That said, I'd recommend first trying this out on a test or development server. I think it should work, but it'd be worth testing more thoroughly how DSpace behaves when one Item object has multiple Handles (and for example, whether both handles appear on the Item splash page, etc). I'd recommend testing basic functionality like browse/search/reindex. I suspect they all should work, but as this isn't a documented feature, it's worth double checking. Let us know how it goes (please report back on this list), as this seems like it might be of interest to others. - Tim On Wed, Jun 13, 2018 at 11:51 PM Fitchett, Deborah <deborah.fitch...@lincoln.ac.nz<mailto:deborah.fitch...@lincoln.ac.nz>> wrote: Kia ora all, We’re occasionally getting duplicate records created in Dspace with no way to resolve the issue other than to withdraw the earlier record and go forward with the more recent one.(1) But of course we don’t really want the handle of the earlier record to result in a dead-end – we’d like it to resolve to the new record, or at least be redirected there. We have metadata fields dc.relation.isreplacedby and dc.relation.replaces. These seem to have no functional purpose in Dspace (ie it doesn’t do any automatic redirects), it’s just information. If the item is *not* withdrawn, I could add some javascript to the page to accomplish the redirect that way. But I’m not sure it’s the cleanest way. I’m looking at the handle table in the database and wondering – what if I simply find the row with the handle that’s currently linked to the old record, and update it to point to the resource_id of the new record(2)? Then we could withdraw the old record but people following the old link would still get to what they want. Would this do what I’m thinking? Would there be any problems I’m not seeing with having two handles point to the same record? And/or is there a better way? How would you deal with a case like this? Deborah (1) Due to synchronisation with Symplectic Elements which works 99.9% of the time but not 100%. (2) I’m happy messing directly in the database in general, having done it with the metadatavalue table a pile of times – obviously always with much testing and great care. I haven’t touched the handle table before though. ________________________________ P Please consider the environment before you print this email. "The contents of this e-mail (including any attachments) may be confidential and/or subject to copyright. Any unauthorised use, distribution, or copying of the contents is expressly prohibited. If you have received this e-mail in error, please advise the sender by return e-mail or telephone and then delete this e-mail together with all attachments from your system." -- You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech+unsubscr...@googlegroups.com<mailto:dspace-tech+unsubscr...@googlegroups.com>. To post to this group, send email to dspace-tech@googlegroups.com<mailto:dspace-tech@googlegroups.com>. Visit this group at https://groups.google.com/group/dspace-tech. For more options, visit https://groups.google.com/d/optout. -- Tim Donohue Technical Lead for DSpace & DSpaceDirect DuraSpace.org | DSpace.org | DSpaceDirect.org -- All messages to this mailing list should adhere to the DuraSpace Code of Conduct: https://duraspace.org/about/policies/code-of-conduct/ --- You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech+unsubscr...@googlegroups.com. To post to this group, send email to dspace-tech@googlegroups.com. Visit this group at https://groups.google.com/group/dspace-tech. For more options, visit https://groups.google.com/d/optout.