[#CODEBASE-244] refactor solr search default config - Project Blacklight Jira

Details

Type: Improvement
Status: Closed
Priority: Major
Resolution: Fixed
Affects Version/s: 2.5
Fix Version/s: 2.6
Component/s: None

Description:

Hide

Currently we have config[:default_qt] and
Blacklight.config[:index][:num_per_page] . These are used by
SolrHelper#solr_search_params (a mix-in to CatalogController) to provide
default Solr values for a search operation.

I plan to consolidate these into the more flexible:

config[:search_solr_defaults], which will be a hash of _any_ arbitrary
solr params. No more lines of code, more flexible, the facet.fields can
be specified here IF you want BL to send them, or left out if you do not.

The old config values may stop working, I worry about too many attempts
to support backwards compatibility resulting in spaghetti code in BL,
there isn't too large an install base yet, this is a simple change, you
may have to change your config.

Now, currently ALSO we have SolrDocument.default_params[:search], which
_looks_ like it would already be used for setting default search
params. This is at the SolrDocument "model" level, not at the
controller level. Setting SolrDocument.default_params[:search] will
cause those defaults to be used when SolrDocument#search is called.
However, Blacklight never actually calls SolrDocument#search.
SolrDocument mixes in RSolr::Ext::Model, but this
"default_params[:search]" stuff doesn't come from the mix-in, it's local
to BL, and not actually used by BL.

I plan to completely remove the (currently ineffective)
default_params[:search] stuff, less code, less confusion.

So please, share opinion now, or I'll go ahead and do it!

Will also make ~~CODEBASE-233~~ trivial to solve, don't have solr_search_params automatically include facet fields, instead you can include them in config.default_search_params if you want, or not if you don't want.

Show
Currently we have config[:default_qt] and Blacklight.config[:index][:num_per_page] . These are used by SolrHelper#solr_search_params (a mix-in to CatalogController) to provide default Solr values for a search operation. I plan to consolidate these into the more flexible: config[:search_solr_defaults], which will be a hash of _any_ arbitrary solr params. No more lines of code, more flexible, the facet.fields can be specified here IF you want BL to send them, or left out if you do not. The old config values may stop working, I worry about too many attempts to support backwards compatibility resulting in spaghetti code in BL, there isn't too large an install base yet, this is a simple change, you may have to change your config. Now, currently ALSO we have SolrDocument.default_params[:search], which _looks_ like it would already be used for setting default search params. This is at the SolrDocument "model" level, not at the controller level. Setting SolrDocument.default_params[:search] will cause those defaults to be used when SolrDocument#search is called. However, Blacklight never actually calls SolrDocument#search. SolrDocument mixes in RSolr::Ext::Model, but this "default_params[:search]" stuff doesn't come from the mix-in, it's local to BL, and not actually used by BL. I plan to completely remove the (currently ineffective) default_params[:search] stuff, less code, less confusion. So please, share opinion now, or I'll go ahead and do it! Will also make ~~CODEBASE-233~~ trivial to solve, don't have solr_search_params automatically include facet fields, instead you can include them in config.default_search_params if you want, or not if you don't want.

Issue Links

pre-requisite

This issue is a pre-requisite for:
~~CODEBASE-150~~ solr facet fields should be in the request handler, not arguments in the URL

Activity

Ascending order - Click to sort in descending order

Hide

Permalink

Jonathan Rochkind added a comment - 18/Aug/10 4:41 PM

Realized that when I say "get rid of SolrDocument.default_params", really what I'm talking about is getting rid of the WHOLE Blacklight::Solr::Document::DefaultFinders. None of this is used at all, get rid of un-used code, keep things clean, we have other ways of doing this that we're using (mainly using stuff built-in to RSolr::Ext::Model, instead of using things from BL specifically, like this).

Show

Jonathan Rochkind added a comment - 18/Aug/10 4:41 PM Realized that when I say "get rid of SolrDocument.default_params", really what I'm talking about is getting rid of the WHOLE Blacklight::Solr::Document::DefaultFinders. None of this is used at all, get rid of un-used code, keep things clean, we have other ways of doing this that we're using (mainly using stuff built-in to RSolr::Ext::Model, instead of using things from BL specifically, like this).

Hide

Permalink

Jonathan Rochkind added a comment - 19/Aug/10 5:09 PM

DONE.

Note that config[:default_qt] and config[:index][:num_per_page] now do nothing! You may have to change your config, new style:

config[:default_solr_params] = {:qt => "foo", :per_page => 10}

Note also that if you WANT facet.field to be sent to solr by BL, you may have to include that too:

config[:default_solr_params] = {:qt => "foo", :per_page => 10, :"facet.field" = ["a", "b", "c"]}

Show

Jonathan Rochkind added a comment - 19/Aug/10 5:09 PM DONE. Note that config[:default_qt] and config[:index][:num_per_page] now do nothing! You may have to change your config, new style: config[:default_solr_params] = {:qt => "foo", :per_page => 10} Note also that if you WANT facet.field to be sent to solr by BL, you may have to include that too: config[:default_solr_params] = {:qt => "foo", :per_page => 10, :"facet.field" = ["a", "b", "c"]}

Blacklight Plugin

refactor solr search default config

Details

Issue Links

Activity

People

Dates