Maybe I am not understanding correctly, but have you overlooked the qf parameter for Edismax?
http://wiki.apache.org/solr/ExtendedDisMax#qf_.28Query_Fields.29 Suppose you want to search for the phrase "apples and bananas" in title, summary, and body. You also want it to have greater emphasis when the search term is found in title and description. The way you would do it is: q = apples and bananas qf = title^100 content description^10 That's it. Now it'll search for "apples and bananas" in all 3 fields. Edismax was basically designed to do...what you want to do. You'll probably also find the "mm" parameter and the "pf" parameters immensely useful. -----Original Message----- From: z...@navigo.com [mailto:z...@navigo.com] Sent: Monday, February 25, 2013 12:06 PM To: solr-user@lucene.apache.org Subject: 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 <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.
