lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Rochkind <rochk...@jhu.edu>
Subject Re: nested querries, and LocalParams syntax
Date Tue, 01 Jun 2010 22:21:29 GMT
I am just trying to figure it out mostly, the particular thing I am 
trying to do is a very general purpose mapper to complex dismax nested 
querries.  I could try to explain it, and we could go back and forth for 
a while, and maybe I could convince you it makes sense to do what I'm 
trying to do.  But mostly I'm just exploring at this point, so I can get 
a sense of what is possible.

So it would be super helpful if someone can help me figure out escaping 
stuff and skip the other part, heh.

But basically, it's a mapper from a "CQL" query (a structured language 
for search-engine-style querries) to Solr, where some of the "fields" 
searched aren't really Solr fields/indexes, but aggregated definitions 
of dismax query params including multiple solr fields, where exactly 
what solr fields and other dismax querries will not be hard-coded, but 
will be configurable.  Thus the use of nested querries. So since it ends 
up so general purpose and abstract, and many of the individual 
parameters are configurable, thus my interest in figuring out proper 
escaping.

Jonathan

Yonik Seeley wrote:
> 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