Document breaking change regarding use of `solr_local_params` as of Solr 7.2

[magibney]

For users interested in upgrading Solr backend, Solr 7.2+ introduces a change in handling of local parameters (solr_local_parameters) that is likely to break many existing BL configurations.The upstream change SOLR-11501 introduces a change that I'll paraphrase as:
Local parameters in Solr queries (solr_local_parameters, in BL parlance) are treated as naive user input starting with Solr 7.2. This encompasses (but is not limited to) query parser switching.

The default blacklight generator, and consequently many existing Solr configurations, incorporate heavy use of solr_local_parameters in catalog_controller.rb search field configuration.

Most existing configurations can be made compatible with the new query parsing restrictions by setting top-level query parameters (BL solr_parameters, as opposed to solr_local_parameters) for defType, and specific parser configuration (e.g., for defType=edismax: qf, pf, etc.).

If you have a reason to need local parameters, set the top-level defType=lucene. This is the approach taken by the blacklight_advanced_search commit (below), and is appropriate for instance in cases where complex queries are constructed (e.g., using _query_="..." subqueries.

Some relevant links:

• https://github.com/sul-dlss/SearchWorks/pull/1900/files (example of how to update existing config)
• Update query to work with Solr 7.2 #1820
• projectblacklight/blacklight_advanced_search@0432167bedf

This documentation-related issue follows on a number of closed PRs and issues:
#1838, #1839, #1925, #2018

[mejackreed]

@magibney where do you see this best documented?

[magibney]

@mejackreed thanks for following up. I'm not that familiar with BL documentation. Do you think that the README_SOLR would be a good place? It would be nice if there was a compatibility matrix or something, just to have all this type of info in one place.
Part of the problem is that this issue is most likely to affect people who are trying to upgrade existing configurations to work with new Solr versions; many people in that boat are likely to be past the point where they'd be consulting README_SOLR. Maybe a prominent message to the community? I responded to two posts in one day (a couple of weeks back) on the "Blacklight Development" Google groups page that I'm 90% sure were a consequence of this exact issue. It can manifest in pretty strange ways!

[mejackreed]

Sure, I'm 👍 for README_SOLR or the list. Also I think this issue will serve as a great starting point for adopters having issues with this upgrade path.

I'm not sure what actionable work is left for this issue? I don't think we can document all of the compatibility complications for all time, but this may serve as useful guidance?

[ebenenglish]

I believe that this issue may be breaking some default Blacklight functionality?

The 'Subject', 'Title', and 'Author' searches on the BL demo site (aka use of alternate qf and pf) don't return any results, even when using terms that are obviously in those fields.

[cdmo]

Thanks for these notes. The only catch for me in implementing this for Solr 7.4 was that I needed to enclose the pf fields in single quotes or I get "Bad Request" errors and then Solr log shows something along the lines of "Expected identifier at pos"

-        'spellcheck.dictionary': 'title',
-        qf: '${title_qf}',
-        pf: '${title_pf}'
+          'spellcheck.dictionary': 'title',
+          qf: '\'${title_qf}\'',
+          pf: '\'${title_pf}\''

After making that change advanced search for title worked. Note I am using the latest from the blacklight_advanced_search gem, which specifies lucene as the defType for Advanced searches and I am then able to use edismax as the defType in the nested query. i.e.,:

    config.advanced_search[:query_parser] ||= 'edismax'