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.
