|
So I actually did find the part of Blacklight code to be easily modified for this. ApplicationHelper#solr_search_params. (A method that is getting rather HUGE and should probably be broken up at some point, but not this point!).
That method is already doing a whole bunch of Solr request param mapping. So doing one more piece here is not out of place. It's just one more piece BL will do itself instead of relying on rsolr-ext magic, making me and Erik and happy, making the code somewhat more transparent, and using the Erik-recommended way of sending fq to avoid escaping issues. ApplicationHelper#solr_search_params will generate Solr "fq" as appropriate, using the {!raw} format, instead of sending :phrase_filters to rsolr-ext. If anyone has a concern with this, let me know, otherwise I'll commit if there seem to be no concerns? It's just a few lines of code, and a few rspec tests changed to spec fq instead of phrase_filters. More from Erik on why switching to {!raw} here really makes sense:
(1:06:39 PM) erikhatcher: it is because of escaping... because that is ugly. but also because drilling into a facet generally should simply be a TermQuery ultimately (1:06:53 PM) jrochkind: so escaping, plus possibly somewhat more efficient execution? (1:07:16 PM) erikhatcher: and using the lucene query parser with field:"whatever \" you want" is potentially mangling what you meant (1:07:31 PM) jrochkind: mangling in ways that do not have to do with escaping? Weird. (1:07:45 PM) erikhatcher: it is analyzing the text, dealing with position stuff as a phrase query, etc (1:08:11 PM) erikhatcher: you don't need analysis involved when it's a direct exact term value you're querying for Changed and tested in: http://github.com/jrochkind/blacklight/tree/better_solr_fq
I'll give it a day or two to see if anyone has concerns, if not, I'll commit (can always be revert'ed if for some reason it's a problem) |
|||||||||||||||||||||||||||||||||||||||||||
Any advice, Matt or anyone else?