Repository navigation
Metadata indexed by ItemAuthorityLookupIndexPlugin is overwritten by metric updates #551
Description
Describe the bug
DSpace-CRIS version: tested on 2025.02.01.01
The class org.dspace.discovery.ItemAuthorityLookupIndexPlugin indexes multiple metadata values into the Solr document field itemauthoritylookup, with the metadata field list configured in:
DSpace/dspace/config/spring/api/discovery.xml
Lines 45 to 55 in 1f33d58
| <bean id="itemAuthorityLookupIndexPlugin" class="org.dspace.discovery.ItemAuthorityLookupIndexPlugin"> | |
| <property name="additionalFields"> | |
| <list> | |
| <value>crisrp.name</value> | |
| <value>crisrp.name.variant</value> | |
| <value>crisrp.name.translated</value> | |
| <value>person.givenName</value> | |
| <value>person.familyName</value> | |
| </list> | |
| </property> | |
| </bean> |
However, metric-related indexing script like ./dspace store-metrics, ./dspace update-metrics-in-solr, and ./dspace index-discovery --build (which triggers a metric update in its secondary phase) wipe out the extra metadata fields indexed in itemauthoritylookup, leaving only the title (dc.title).
As a consequence, the feature that suggests person profiles by multiple name variations (official, translated, variants, etc.) when adding authors/editors inside publications submission/edit forms fails to search suggestion names other than dc.title.
To Reproduce
Steps to reproduce the behavior:
- Configure an item or person entity with multiple metadata fields indexed by
ItemAuthorityLookupIndexPlugin(e.g., author name variants likecrisrp.name.variant). - Run
./dspace index-discovery --build. - Query Solr:
curl "http://localhost:8983/solr/search/select?q=search.resourceid:<UUID>&fl=title,itemauthoritylookup". Notice that only thetitlevalue is present initemauthoritylookup. - Edit and save the item via the frontend UI, or run
./dspace index-discovery --build -m. - Query Solr again. Notice that all related metadata fields defined in
discovery.xmlare now present initemauthoritylookup. - Run
./dspace update-metrics-in-solror./dspace store-metrics. - Query Solr again. Notice that the metadata fields have been wiped out again, leaving only
title.
Expected behavior
Periodic or background Solr indexing of items metrics should not overwrite or wipe out index values populated by discovery plugins for the authority suggestion system.
Findings
The root cause is seems to be a conflict between Solr's Atomic Updates and the <copyField> configuration in the search core:
DSpace/dspace/solr/search/conf/schema.xml
Lines 399 to 400 in 1f33d58
| <copyField source="title" dest="itemauthoritylookup"/> | |
| <copyField source="title" dest="itemauthoritylookupexactmatch"/> |
When metric update script run, they send Solr Atomic Updates for metric fields (e.g., metric.view, metric.download).
In Apache Solr, applying an atomic update re-evaluates all directives on the document using stored fields. Because
itemauthoritylookup is a copyField destination, Solr replaces its entire content with the value of title, discarding any values directly injected by ItemAuthorityLookupIndexPlugin.
Updating an item through the frontend UI or running index-discovery -m performs a full document re-index without atomic metric updates, which is why the metadata survives until the next metric task runs.
Activity