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 <rochk...@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
