lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yonik Seeley <yo...@lucidimagination.com>
Subject Re: nested querries, and LocalParams syntax
Date Tue, 01 Jun 2010 21:10:11 GMT
It's not clear if you're just trying to figure it all out, or get
something specific to work.
If you can give a specific example, we might be able to suggest easier
ways to achieve it rather than going escape crazy :-)

-Yonik
http://www.lucidimagination.com



On Tue, Jun 1, 2010 at 5:06 PM, Jonathan Rochkind <rochkind@jhu.edu> wrote:
> 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.
>
> Jonathan****
>
> 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...
>>
>> http://www.lucidimagination.com/blog/2010/05/23/whats-a-dismax/
>>
>> ... 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 <http://wiki.apache.org/solr/SolrQuerySyntax#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
>>
>> ...in that example, neither the XXX or "lucene" QParsers are ever used.
>>
>>
>>
>> -Hoss
>>
>>
>>
>

Mime
View raw message