Hmmm, well, the lucene query parser does basic backslash escaping, and so does local params within quoted strings. You can also use parameter derefererencing to avoid the need to escape values too. Like you pointed out, using single quotes in some places can also help.
But instead of me trying to give you tons of examples that you probably already understand, start from the assumption that things will work, and if you come across something that doesn't make sense (or doesn't work), I can help with that. Or if you give a single real example as a general pattern, perhaps we could help figure out the simplest way to avoid most of the escaping. -Yonik http://www.lucidimagination.com On Tue, Jun 1, 2010 at 6:21 PM, Jonathan Rochkind <rochk...@jhu.edu> wrote: > 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 >>>> >>>> >>>> >>>> >> >> >
