Migration DSpace 4.2 --> DSpace 6.3 - index-discovery problem

[Luiz Ricardo Rech]

Hello guys.

We are conducting tests to verify the possibility of migrating our data from version 4.2 of DSpace to version 6.3.

We set up a virtual server for this and performed a clean installation in order to start testing. The installation went smoothly. However, after importing the database, copying the folders (assetstore and solr / statistics) and performing the database migration, when we perform index-discovery, indexing does not occur, except for communities. These are displayed normally, but deposits on them are not. The search also does not display any results. New deposits on this basis also work without problems. Only content imported into the bank is not indexed.

Checking the DSpace log, we find what appears to be the problem:

ERROR org.dspace.discovery.SolrServiceImpl @ No choices plugin was configured for field "dc_subject_cnpq".

This is a specific field of a customization made on a DSpace fork. However, would you know if there is a way to ignore or work around this situation? Has anyone experienced this similar situation or would you have any idea how to fix it?

This occurs in all deposits. We have tried to use routine modifiers, such as index-discovery -f and even index-discovery -b, without success.

Universidade Estadual do Centro-Oeste - Unicentro

http://www.unicentro.br

[Jose Blanco]

I found another user with a similar problem:

http://dspace.2283337.n4.nabble.com/ERROR-creating-index-discovery-td4676204.html

I found this recommendation very good:

"Always start with the default configuration from the new version and put your changes in there, not the other way around."

See if there is something in that thread that is helpful.

-Jose

--
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 Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dspace-communi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-community/64867e6b-5ce8-4dc8-8d32-aa84258fe607n%40googlegroups.com.

[Luiz Ricardo Rech]

Nope, but thanks Jose! And about the configuration, default is fine and working good. The problem is when I import the database.

I am considering the possibility of migrating via AIP, if I'm unable to resolve this situation.

[Kim Shepherd]

Hi Luiz, were you using Authority Control for the dc.subject.cnpq field in the past?

When SolrService indexes a metadata value that is authority controlled, it tries to get the label / variant terms out of the authority index to include it in the search terms for the item.

From what I'm seeing in SolrServiceImpl, I think the problem is that the field is enabled for authority control somewhere in dspace.cfg, or the spring authority config, but there is no ChoiceAuthority plugin selected for the field.

So the service thinks it needs to try to query the authority index, since the field is configured as controlled, but doesn't know how to because the plugin (which is responsible for returning variant names, labels etc) isn't specified.

There are a few suggestions I have:

1. if you do use authority control for this field, check which plugin you'd been using previously (look in past config) and see if you can re-enable it -- it might be that it's been missing for a while in your previous instance but hadn't been a major issue if items with that field weren't being indexed or re-indexed

2. if you don't actually use authority control for this field, make sure it isn't "half-configured" in dspace.cfg, and in the (confusingly-named) orcid-authority-services.xml file.

3. if you don't use authority control but #2 doesn't work, i can see a configuration property checked in the service that isn't documented, but might help: discovery.index.authority.ignore.dc.subject.cnpq = true

This allows authority control to continue functioning but doesn't try to index any authority terms. However, you could still end up with other issues outside of indexing if you have that field enabled for authority control, but without a plugin specified, so #2 is probably better overall.

Also note, if you were using authority control in your previous instance and need to preserve those records, you'll probably need to export and import the authority index to your new server so you have the actual authority data stored with the right UUIDs. (this can be done with standard solr CSV query and update, and in new versions of DSpace can be done with the solr-statistics-export command specifying the authority core)

Cheers

Kim

0CCB D957 0C35 F5C1 497E CDCF FC4B ABA3 2A1A FAEC

To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-community/3aad9101-6f44-4f6c-82a6-ad20574c910an%40googlegroups.com.

[Luiz Ricardo Rech]

Kim, thanks for your thoughts about this question. I'll consider and try to check everything.

Much apreciated. Thanks again.