Bug #7083


Metadata/data objects which have obsoletedBy field ignore the resource map index

Added by Jing Tao over 7 years ago. Updated over 7 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


Hi Bryce:

I looked at the index of the 16 objects and found 5 of them don't have the value of resource_map_urn:uuid:2e3c8c4c-e606-4710-b321-8edc4d506b0a at the resourceMap element:


So this is the reason you only get 11 documents when you query this resource map value.

And all of the five objects have the field "obsoletedBy" and the other 11 object don't have the field.

The reason why I looked at the field "obsoletedBy" is I recently found that there was a bug in the d1_cn_index_processor component - when you index a resource map, the component in the resource map will ignore the resource map if it has the "obsoletedBy" field. So this issue sounds like the reflection of this bug.

I will look at the metacat index code to make sure.



On 8/8/16 12:13 PM, Bryce Mecum wrote:

So @scng got a hold of me to ask about strange behavior where there package table on two dataset pages are not showing the right number of files. This is a write up of what she told me and what I found so that someone else, Jessica Couture or Chris Jones can see about addressing it. This is a blocker on Bill Simpson's ticket RT12930.

This applies to two packages:

O-Buoy 8 (needs link)
O-Buoy 15

These two packages were recently updated to make them editable (adding otherEntity elements to the EML) by @scng using the R package.

If you look at O-Buoy 15, you'll see ten data objects in the package. However, the R @scng wrote intended to add 15 data objects to the package. If you look at the resource map, resource_map_urn:uuid:2e3c8c4c-e606-4710-b321-8edc4d506b0a, you'll see it aggregates+documents 16 PIDs (metadata + 15 data):

Here's an invalid and abridged section from the resource map, converted to Turtle format before pasting here:
ore:aggregates <>
<> ;

So it looks like the Resource Map is correct which makes sense because it was generated using the R package.

The package view uses the Solr query resourceMap:{RESOURCE_MAP} to fill in the table. If you run this query you see the 11 objects, not 16. This explains the table view not showing all the files.

If you look at the documents section of the metadata object's Solr doc, you'll see the 16 objects it documents (itself + 15 data objects.

So what's going on here? Am I wrong to think that it's just the index that is showing the wrong information?

I have forced a reindex with no change
I have not checked the arctica logs for any errors

Related issues

Has duplicate Metacat - Bug #7093: Metacat-index is not indexing all package members correctlyNewJing Tao08/26/2016

Actions #1

Updated by Jing Tao over 7 years ago

  • Status changed from New to Closed

It was fixed in the d1_cn_index_processor component. I created a new 2.2.1 tag and built it on Jenkons. Please see:

In the metacat-index pom.xml file, the dependency of d1_cn_index_processor was modified to the version 2.2.1.

Actions #2

Updated by Chris Jones over 7 years ago

  • Has duplicate Bug #7093: Metacat-index is not indexing all package members correctly added

Also available in: Atom PDF