Avoid errorId in search

[nichtich]

Links to issues use the Solr field errorId but this is not stable on updates. At least for "unknown subfield" type of errors the search can better use the specific subfield index. For instance instead of errorId:112 use PICA 017Ex_ss:* (unknown PICA subfield 017E$x) to list all records having this subfield.

Linking to errors based on unknown field requires #128.

[pkiraly]

The errors are stored in 3 places:

• files
• a sqlite3 database
• Solr
  The Solr indexing happen later, but sqlite index is part of the validation.
  What we can do to check if Solr index is older or not than the validation. If it is newer, we use Solr, otherwise we use the sqlite3.

[nichtich]

Having three places to gather information from and allowing them to get out of sync seems no good. I'd prefer to simplify the application instead of adding more cases. Is there an actual use case where outdated solr makes sense to support? -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

[pkiraly]

The ideal case is that validation is running in the same session as Solr (run all runs all the analyses and Solr). If I understand the situation correctly you problem is that after validation you did not run Solr indexing, that is why Solr is outdated. Is that true? If yes, then the solution is simply run Solr again. If it is not possible for whatever reason (e.g. becuase it takes too much time), then the solution I described might work.

[nichtich]

If I understand the situation correctly you problem is that after validation you did not run Solr indexing, that is why Solr is outdated.

No, the problem is to not have stable links to errors because errorId is just an internal identifier not stable across time. Solr index query 017Ex_ss:* is stable unless qa-catalogue changes how fields are indexed. If people share the link to list of records with a specific error, the list should always lead to same error.

[nichtich]

The search link can be adjusted as following

• undefined subfield a of field XXXX: search XXXXa_ss:*
• undefined field XXXX: search XXXX_count_i:*(requires configurationindexFieldCounts`)
• repetition of non-repeatable field XXXX: search XXXX_count_i:[1 TO *] (requires configuration indexFieldCounts)
• repetition of non-repeatable subfield a of field XXXX: search XXXXa_count_i:[1 TO *] (requires configuration indexSubfieldCounts not implemented yet)

[pkiraly]

Good idea! For PICA it will work perfectly. For MARC: I am not sure if all other errors can be transformed into queries like this, but it is worth to investigate. Based on a quick overview of the error types most of them will work.

[nichtich]

If ErrorId is needed, it might be generated as hash value of the actual search (#187 (comment)), so it will be stable as well.