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 >> >> >> >
