Thanks for reporting back on your findings, Deborah. It sounds like the act of pointing to handles at one item "works"...but, removing the handle from the withdrawn item is the core issue. I'm not surprised that DSpace cannot fully manage Items without handles -- as handles are still very "built into" DSpace.
I've logged this issue as a bug: https://jira.duraspace.org/browse/DS-3993 In the meantime, one option to possibly work around this issue would be to define a "fake/dummy" handle for the withdrawn item. For example, give it a handle of "withdrawn/[old-id]" or something. This isn't exactly ideal, but if the only issue is that the Handle cannot be null, this might be a possible workaround. Nonetheless, honestly, Claudia's fix seems very reasonable and it seems to involve much less "messing around in the database". So, I wouldn't fault you for looking towards simply using that. - Tim On Wed, Aug 22, 2018 at 8:56 PM Fitchett, Deborah < [email protected]> wrote: > 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 <[email protected]> > *Sent:* Friday, 15 June 2018 2:42 AM > *To:* Fitchett, Deborah <[email protected]> > *Cc:* [email protected] > > > *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 < > [email protected]> 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 [email protected]. > To post to this group, send email to [email protected]. > 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 > -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/dspace-tech. For more options, visit https://groups.google.com/d/optout.
