Fields to add for search index

[sfisher]

The initial pass got most of the fields, but based on the search/filtering detailed code, I need to add the following fields:

• linkIsBroken
• hasIssues

This turns out to be somewhat icky since it seems like most thing in search are simply derived values/method return values from other objects.

hasIssues seems to have a method at identifier.computeHasIssues() (but it's on the Search class). linkIsBroken only has values in the search database table and seems to be set from link checker.

So it becomes tricky to set these values if we plan to get rid of the Search table in the future. Almost everything else in search is a derived value but these aren't.

Writing these items to OpenSearch directly:

• but this has some problems since the idea is that a full search record could be regenerated easily at any time from data derived form the database.
• So if they're updated independently and the full OpenSearch record is regenerated then it may clobber the value if it's not available.

Set these values elsewhere in the database (maybe identifier table?):

• This has the advantage that these values can be derived like everything else.

• Regenerating a search record at any time should have the correct value since everything is derived (which IMO, makes the most sense for search).

• Deal with these non-derived values by either making them derived or adding some tricky code before any release.

[sfisher]

Jing suggested that we might be able to leave the ezidapp_searchidentifier in place but remove all the columns that are no longer needed (so just leave these flags, the ID and some other things).

I think this may be a good way forward and would minimize the amount of code we need to change.

[sfisher]

Let's go with Jing's idea above and do some data cleanup after OpenSearch is released by cleaning up the table once working.