User Query Processing Sanity Check
Have been working with Solr for about 6 months, straightforward stuff, basic keyword searches. We want to move to more advanced stuff, to support 'must include', 'must not include', set union, etc. I.e., more advanced query strings. We seem to have hit a block, and are considering two paths and want to make sure we have the right understanding before wasting time. To wit: - We have many fields to search, fieldA, fieldB, fieldC, etc. - We need field level boosting, fieldA > fieldB > fieldC, etc. - We're happy to use EDisMax query syntax: "", +, -, OR, AND, (), and : superficial syntax. Passing the query straight through doesn't seem work because "foo bar fieldB:baz" searches foo and bar in the default field only, but we want to search multiple fields. The trick of copying multiple fields into a single artificial default field seems to fail on the second requirement. So, we end up parsing the Lucene syntax ourselves, and rebuilding the query my multiplying the fields so that: foo bar fieldB:baz -> (fieldA:foo OR fieldB:foo OR fieldC:foo) AND (fieldA:bar OR fieldB:bar OR fieldC:bar) AND (fieldB:baz) Technically, this is straightforward enough, but it seems a shame since the EDisMax query parser seems like it's *almost* what we want, if it weren't for the reality of the singular default field. Are we correct to build our own mini-parser that takes query strings and multiplies the fields for free-field sub-predicates? Or is there a simpler path that we're overlooking? Regards, Zane -- View this message in context: http://lucene.472066.n3.nabble.com/User-Query-Processing-Sanity-Check-tp4042783.html Sent from the Solr - User mailing list archive at Nabble.com.
Unexpected '-' Results
We want to treat all optional parameters as required. I thought setting: q.op=AND and mm=100% (using edismax request handler) would achieve this result, but I get unexpected results 1) medical => 4,425 2) medical retired => 272 3) medical retired -working => 5,041 4) medical AND retired AND -working => 216 We expect the 3rd and 4th queries to be equivalent, but we're obviously missing something. It doesn't seem to be an issue with the number of terms, since: medical retired husband => 52 Regards, Z -- View this message in context: http://lucene.472066.n3.nabble.com/Unexpected-Results-tp4043107.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: Unexpected '-' Results
Thanks for the heads up. I"ll keep an eye on the issue. Based on the comments, there's no workaround, I suppose? -- View this message in context: http://lucene.472066.n3.nabble.com/Unexpected-Results-tp4043107p4043239.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: Unexpected '-' Results
Yes... we were trying to avoid getting between solr and the user query, but that's a good suggestion on a relatively simple approach. To make it full correct, I fear, gets towards a full formal query parser, but we may be able to slide. For now, we can leave it as a known issue and just let the power searchers know. Thanks for your help. -- View this message in context: http://lucene.472066.n3.nabble.com/Unexpected-Results-tp4043107p4043418.html Sent from the Solr - User mailing list archive at Nabble.com.
Formal Query Grammar
I found where this had been asked, but did not find an answer. Is there a formal definition of the solr query grammar? Like a Chomsky grammar? Previous ask: http://lucene.472066.n3.nabble.com/FW-Formal-grammar-for-solr-lucene-td4010949.html -- View this message in context: http://lucene.472066.n3.nabble.com/Formal-Query-Grammar-tp4043419.html Sent from the Solr - User mailing list archive at Nabble.com.
