: Thanks for the reply. And sorry for sounding impatient -
: I've been working in the weekend and I wasn't sure if I expressed
: my question well, hence why the second email :)

yeah .. my apologies as well, i realize now i didn't answer your question
very well at all ... i've been sick and it's wrecking havock with my mood.

: I understand I can url-encode the space. My question, which I failed
: to mention in my first email, is that, what if the search term
: in fq also has a space in it? Quoting with " " does not seem to
: be a solution because quotes may appear in the query as well?
:
: fq=+name:jack smith +section:0

start by ignoring the URL escaping, treat the concept of a filter query
exactly as you would any other lucene query string for the standard
request handler ... if you want to require that the name field contain the
phrase "jack smith" and that the section field contain the number 0, then
that query can be expressed as...

     +name:"jack smith" +section:0

if you wnat your query to contain a literal '"' character, then the Lucene
QueryParser requires that you backslash escape it...

     +name:"jack quote\" smith" +section:0

now all you have to do is URL escape that whole thing, and you can pass it
to Solr as the value of an fq (or q) param.

you cna see that it's working and doing what you want by looking at the
debugQuery output.

the key the wiki is trying to point out to you, si thta if you tend to
have a lot of differnet Filter Queries that look like this..

     +name:"jack smith" +section:0
     +name:"Joe smith" +section:0
     +name:"lee harvey" +section:0

...it's going to be more efficient from a caching perspective to break
those up so that "section:0" is used as it's own fq.

: BTW, space is sometimes encoded as %20, sometimes as "+".
: So, solr expects %20 in this case? Or both are fine?

this is where i realized i did a really bad job answering your question
... + as an escping for space is fine .. it's unfortunate thta it's also
the charcter denoting a mandatory clause in a lucene query, and that when
splitting your big fq into two seperate fqs you no longer need the + to
make them mandatory since they are seperate params that by definition must
match.


-Hoss

Reply via email to