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 <field>:<term> 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.
