"OR-ing" facet values in RSolr ?

[Naomi Dushay]

Hi folks,

We are hitting some fun times with facet values.

Imagine your facet values are displayed as check boxes, rather than
links. Now users can select multiple check boxes: They want to see
results that have both English and Spanish items -- which, oddly
enough, translates to a "English OR Spanish" language result.

So, the ultimate query to Solr needs to look something like:

fq=language_facet:(English OR Spanish)

Does RSolr allow this? (Keep reading until the end)

http://jira.projectblacklight.org/jira/browse/CODEBASE-105 notes a
(fixed) bug, whereby facet values were combined with "OR" instead of
with "AND." (I do believe "AND" is the correct default behavior.
However, now I have a use case for "OR".)

I can imagine putting this in the hash of params sent to
Blacklight.solr.find:
solr_params = {
stuff,
"fq" => "language_facet:(English OR Spanish)",
more_stuff
}

BUT - it is further complicated because there can be mulitple fq
parameters in the URL, but a Ruby hash can only cope with a single
instance of a key. For example,

Solr wants:
fq=language_facet:(English OR Spanish)&fq=format:Book

How do we express that in RSolr? Like this?

:phrase_filters => [
"language_facet" => [ "(English OR Spanish)" ],
"format" => "Book"
]

Sometimes, an array and a hash just aren't expressive enough, ya know?

- Naomi
p.s. Are we going to encounter this fun for more Solr goodies in our
future?

[Matt Mitchell]

Hi Naomi,

Funny I had to do the exact same thing you're talking about (ORing facets) in an application last week. The UI presents check-boxes for states and other variables etc..

You're first example:

solr_params = {
   stuff,
  "fq" => "language_facet:(English OR Spanish)",
   more_stuff
}

and you said, "BUT - it is further complicated because there can be mulitple fq...". So if you wanted to send multiple fq's, you'd do it like:

solr_params = {
  "fq" => ["language_facet:(English OR Spanish}", "another_field:another_value", "some-other-query"]
}

which results in:

?fq=language_facet:(English OR Spanish}&fq=another_field:another_value&fq=some-other-query

----------------

Your second example uses the "phrase_filters" key which become quoted/phrase values for fq's. So your boolean wouldn't work. For that example, you'd want to put the boolean query in the "filters" key instead, which would result in an un-quoted fq:

solr_params = {
  :phrase_filters =>  {
    "format" => "Book"
   },
  :filters => {"language_facet" =>  ["(English OR Spanish)" ]}
}

which results in:

?fq=format:"Book"&fq=language_facet:(English OR Spanish)

Does that make sense? Currently there isn't a real nifty rsolr-ext API to handle this. I'm sure we could come up with something though?

Matt

[Matt Mitchell]

For direct support in RSolr, what about something like:

Blacklight.solr.select({
    :phrase_filters=>[
        {:title=>['something', :or, 'something else']},
        ['blah', :and, 'blah blah']
    ],
    :filters => {:category=>['this', :or, 'that'}
})

which would end up being:

?fq=title:("something" OR "something else")&fq="blah" AND "blah blah"&fq=category:(this OR that)

In otherwords, use the :or/:and symbols to setup boolean queries? I think this would be pretty easy to do actually.

Matt

[Erik Hatcher]

I have to speak up and say that one thing I regret about the current
version of solr-ruby is the attribute mangling between the Ruby API
and the Solr parameters. filter_queries => fq It's too much magic
and is confusing when looking at the Solr documentation and seeing fq
and then needing to translate that to the Ruby API.

I believe RSolr makes name pass-through its default, right? But
Blacklight has a special transformation that occurs? (just trying to
understand where phrase_filters/filters comes from below)

Personally, I'd like to see:

:fq => ['title:(something OR "something else")', 'blah AND "blah
blah"', 'category:(this OR that)']

Why have phrase_filters just to add quotes?

Don't get me wrong, making an elegant Ruby API and naming things
clearly is something I really appreciate, but I'd really like to see
less magic in Ruby/Solr glue than more.

One thing to think about is where/how this is going to be used in
Blacklight. In what context? What's the action and the parameters
coming in to it?

Erik

[Matt Mitchell]

Hi Erik,

On Tue, Sep 1, 2009 at 9:21 AM, Erik Hatcher <erikh...@mac.com> wrote:

I have to speak up and say that one thing I regret about the current
version of solr-ruby is the attribute mangling between the Ruby API
and the Solr parameters.  filter_queries => fq  It's too much magic
and is confusing when looking at the Solr documentation and seeing fq
and then needing to translate that to the Ruby API.

Actually, RSolr-Ext is handling that extra magic. RSolr by itself does no mapping. 

 

I believe RSolr makes name pass-through its default, right?  But
Blacklight has a special transformation that occurs?  (just trying to
understand where phrase_filters/filters comes from below)

I see what you mean OK. So yes that is RSolr-Ext, not Blacklight or RSolr. The whole purpose of RSolr-Ext is to add a little convenience on top of RSolr, but not too much?
 

Personally, I'd like to see:

   :fq => ['title:(something OR "something else")', 'blah AND "blah
blah"', 'category:(this OR that)']

Yeah that's absolutely doable now and that example is very clear. RSolr-Ext does not hijack any of the real solr params, so keys like q, fq, fl are never messed with. It only "listens" for special keys like, :page, :per_page, :phrase_filters etc..
 

Why have phrase_filters just to add quotes?

Well I guess I just don't like manually creating query string; maybe I'm too lazy :) If you're doing the same thing over and over (joining strings/arrays, quoting) then why not put them into a library of some sort? I do this same type of thing over and over in my projects and now I don't have to because the library does it for me. Of course problems with that include possible confusion and as well as having to learn something more. I definitely see where you're coming from on this Erik.

Don't get me wrong, making an elegant Ruby API and naming things
clearly is something I really appreciate, but I'd really like to see
less magic in Ruby/Solr glue than more.

Right me too (honestly). We don't have to use RSolr-Ext, but BL is definitely depending on it for things like pagination logic, facet response helpers and even spelling suggestion response helpers. I personally think that if the documentation is clear (which might not the case) then using things like :phrase_filters won't be a problem?

One thing to think about is where/how this is going to be used in
Blacklight.  In what context?  What's the action and the parameters
coming in to it?

Currently we use the :f query string param for :phrase_filters. :q is directly mapped to :q. Most of the request building is done in the scope of the controller.

Thanks for your input Erik. I hope I answered your questions. Anyone else have feedback, thoughts or ideas on this stuff?

Matt
 

[Naomi Dushay]

Matt,

Thanks for this.  I'm happy at this moment just knowing how to do it.

- Naomi