Blacklight Plugin

solr facet fields should be in the request handler, not arguments in the URL

Details

  • Type: Task Task
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 2.5
  • Fix Version/s: 2.6
  • Component/s: None
  • Description:
    solr facet fields should be in the request handler, not arguments in the URL
    You should be able to specify as many facet fields in the RequestHandler as you like, and then only display the ones you need in a given context.

Issue Links

Activity

Hide
Jessie Keck added a comment - 23/Oct/09 4:25 PM
When I commented this out and ran Stanford's local tests our hierarchical facet tests failed. This may or may not be required for hierarchical facets but more investigation needs to be done.
Show
Jessie Keck added a comment - 23/Oct/09 4:25 PM When I commented this out and ran Stanford's local tests our hierarchical facet tests failed. This may or may not be required for hierarchical facets but more investigation needs to be done.
Hide
Jonathan Rochkind added a comment - 02/Jun/10 5:02 PM
I want a way that the BL app can send facet.fields OR not, depending on how configured.

Looking at blacklight_config.rb, it kind of looks like it's already supposed to work that way -- I thought it already DID work that way. But it doesn't.

The confusing thing is that we have two parallel structures that deal wtih Solr parameters. Rsolr::Ext and Blacklight itself (largely in SolrHelper#solr_search_params).

And there are two places facets (among other things) are configured, apparently duplicatedly, corresonding to these two structures:

For Blacklight SolrHelper#solr_search_params we have Blacklight.config[:facet], in initializer.

For Rsolr::Ext, we have SolrDocument.default_params[:search][:facets][:fields], also configured in an initializer.

So we actually have a list of facets in two places.

I _thought_ that simply emptying out SolrDocument.default_params[:search][:facets][:fields] would prevent BL from sending facet.fields.

But it does not. Because SolrHelper#solr_search_params is still using the Blacklight.config to send facet.fields.

So.... I think if I _stop_ SolrHelper#solr_search_params from doing that, then RSolr::Ext will STILL send facet.field values based on SolrDocument.default_params. So you will be able to have them sent or not based on that config.

It's a bit confusing to have two different places setting params for solr, but that's kind of the architecture we've got right now, so to address this ticket, still leaving flexibility, without a major re-architecting of BL... that seems the simplest way.
Show
Jonathan Rochkind added a comment - 02/Jun/10 5:02 PM I want a way that the BL app can send facet.fields OR not, depending on how configured. Looking at blacklight_config.rb, it kind of looks like it's already supposed to work that way -- I thought it already DID work that way. But it doesn't. The confusing thing is that we have two parallel structures that deal wtih Solr parameters. Rsolr::Ext and Blacklight itself (largely in SolrHelper#solr_search_params). And there are two places facets (among other things) are configured, apparently duplicatedly, corresonding to these two structures: For Blacklight SolrHelper#solr_search_params we have Blacklight.config[:facet], in initializer. For Rsolr::Ext, we have SolrDocument.default_params[:search][:facets][:fields], also configured in an initializer. So we actually have a list of facets in two places. I _thought_ that simply emptying out SolrDocument.default_params[:search][:facets][:fields] would prevent BL from sending facet.fields. But it does not. Because SolrHelper#solr_search_params is still using the Blacklight.config to send facet.fields. So.... I think if I _stop_ SolrHelper#solr_search_params from doing that, then RSolr::Ext will STILL send facet.field values based on SolrDocument.default_params. So you will be able to have them sent or not based on that config. It's a bit confusing to have two different places setting params for solr, but that's kind of the architecture we've got right now, so to address this ticket, still leaving flexibility, without a major re-architecting of BL... that seems the simplest way.
Hide
Jonathan Rochkind added a comment - 15/Jun/10 11:12 AM
Okay, my solution relied on thinking that RSolr itself would still use SolrDocument.default_params[:search][:facets][:fields].

That does not seem to be the case.

I need to investigate further look into the RSolr code, perhaps talk to Matt about what is intended RSolr behavior, perhaps need to patch Rsolr.
Show
Jonathan Rochkind added a comment - 15/Jun/10 11:12 AM Okay, my solution relied on thinking that RSolr itself would still use SolrDocument.default_params[:search][:facets][:fields]. That does not seem to be the case. I need to investigate further look into the RSolr code, perhaps talk to Matt about what is intended RSolr behavior, perhaps need to patch Rsolr.
Hide
Jonathan Rochkind added a comment - 19/Aug/10 5:11 PM
DONE! As a side-effect of the more general CODEBASE-244
Show
Jonathan Rochkind added a comment - 19/Aug/10 5:11 PM DONE! As a side-effect of the more general CODEBASE-244

People

Dates

  • Created:
    17/Jul/09 12:35 PM
    Updated:
    19/Aug/10 5:11 PM
    Resolved:
    19/Aug/10 5:11 PM