lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Rochkind <>
Subject Re: nested querries, and LocalParams syntax
Date Tue, 01 Jun 2010 21:06:13 GMT
Thanks, the pointer to that documentation page (which somehow I had 
missed), as well as Chris's response is very helpful.

The one thing I'm still not sure about, which I might be able to figure 
it out through trial-and-error reverse engineering, is escaping issues 
when you combine nested querries WITH local params. We potentially have 
a lot of levels of quotes:

q= URIescape(    _local_="{!dismax qf=" value that itself contains a \" 
quote mark"} "phrase query"    "   )

Whole bunch of quotes going on there. How do I give this to Solr so all 
my quotes will end up parsed appropriately? Obviously that above example 
isn't right.   We've got the quotes around the _local_ nested query, 
then we've got quotes around a LocalParam value, then we've got quotes 
that might be IN the actual literal value of the LocalParam, or quotes 
that might be in the actual literal value of the nested query.  Maybe 
using single quotes in some places but double quotes in others will 
help, for certain places that can take singel or double quotes? 

Thanks very much for any advice, I get confused thinking about this.


Chris Hostetter wrote:
> In addition to yonik's point about the LocalParams wiki page (and please 
> let us know if you aren't sure of the answers to any of your questions 
> after reading it) I wanted to clear up one thing...
> : Let's start with that not-nested query example.   Can you in fact use it as
> : above, to force dismax handling of the 'q' even if the qt or request handler
> Quick side note: "qt" determines the ReequestHandler -- if it's "dismax" 
> then you get the DisMaxRequestHandler which in recent versions of solr is 
> just a thin subclass of the SearchHandler subclass where the 
> default value of "defType" (which is used to pick a QParser) is "dismax" 
> instead of "lucene" ... i tried to explain this in a recent blog...
> ... the key thing to note is that "defType" is a param that is specific to 
> SearchHandler -- if you use "qt" to pick some other third party 
> RequestHandler, it's not neccessarily going to do *anything* and the 
> nested params syntax may not work at all.
> : default is something else?  The documentation is confusing: "In standard Solr
> : search handlers, the default type of the main query only may be specified via
> : the defType parameter. The default type of all other query parameters will
> : remain "lucene <>"."
> : 
> : I _think_ it's trying to say that I _can_, even in a standard search handler,
> : force dismax with {!dismax}, I just can't change the type of _other_ query
> : parameters -- rather than saying that I _can't_ use {!dismax} to force dismax
> : type of 'q' in a "standard search handler".  Yes?
> You're right, it is confusing -- the point is tha defType changes the 
> "default QParser type" for the "q" param -- but it doesn't change it for 
> any other param.  I've improved the wording, but the key to keep in mind 
> is that that is completley orthoginal to using the local params syntax 
> that you asked about.
> What that documentation is trying to illustrate is that in this request...
>    defType=XXX&q=AAA&fq=BBB
> ...the "XXX" QParser will be used to parse the value "AAA" -- but the 
> stock "lucene" QParser will be used to parse the "fq" param
> Regardless of the value of defType, if you put the local params 
> syntax ({!foo}) at the begining of a query param, you can force that param 
> to be parsed the way you wish...
>    defType=XXX&q={!foo}AAA&fq={!bar}BBB
> that example, neither the XXX or "lucene" QParsers are ever used.
> -Hoss

View raw message