upgrade to Solr 9.2

[rlskoeser]

dev notes

• depends on test parasolr against solr 9.2 parasolr#80
• test geniza against solr 9 in CI on an upgrade branch
• update geniza qa ansible playbook for solr 9 staging hosts
• test geniza qa on solr 9 thoroughly
• when successful, update geniza production playbook for solr 9

[blms]

results from testing:

• The search seems to work fine, in some cases performing better than the prod site even without the additional feature. (For example, this search is highlighted properly in the test site but not in production.)
• I did get one strange outcome for shelfmark scoped search, where I think it may be evaluating type=edismax directly again after two correct results… the default parser issue coming up again somehow? (here’s that search on prod.)

[blms]

@rlskoeser I think I see what's going on with shelfmark scoped search: the search is being evaluated as

'keyword_query': '{!type=edismax qf=$shelfmark_qf}"T-S 8J16.25"'

which would be inserted into

'q': '{!type=edismax qf=$keyword_qf pf=$keyword_pf v=$keyword_query}'

in place of $keyword_query, producing a sort of nested or wrapped query, with two type=edismax and two qfs in different parts of the query.

It seems like this kind of nesting should work according to the docs (under "boost" here), and it does work for the first couple of results, but it then begins to evaluate type as a part of the keyword query. Maybe this kind of wrapping only works with the boost parser and not edismax?

FWIW, I also noticed that on production, that search seems to produce identical results regardless of whether you include shelfmark:, up until about result number ~375, at which point the results are so barely relevant that it seems inconsequential:

1. with shelfmark:
   
2. without shelfmark:

Despite that, I would say in both cases this actually performs better than the same search on QA, because it finds other shelfmarks that are similar before producing irrelevant results. Seems like it's mostly just using the boosted shelfmark fields as in a normal keyword query.

Again, odd, as I can't find any documented solr changes that would cause this difference, and the query is exactly the same in the current prod code.

Also, as for your question on Slack about whether this happens for other scoped searches—it does not, as this is the only scoped search where we actually use this kind of syntax. I think we do it because shelfmark_qf refers to multiple fields so we need to use qf. In all the other scoped searches we just replace the term with its solr field name, which is always just a single field.

[rlskoeser]

solr upgrade complete!