On 5-Sep-07, at 1:10 PM, Yonik Seeley wrote:
Issues:
- Solr still uses it's own FunctionQuery instead of what was added
back to Lucene. May want to migrate first, or may want to hold off if
changes are needed that would be easier to make here.
I believe that the main thing missing is the various functions (which
should be subclasses of CustomScoreQuery).
- I thought about being able to include queries as a ValueSource (so
one could do functions on relevancy scores). One issue with this is
that some queries need rewriting to work... so rewrite functionality
would need to be added to ValueSource.
ValueSources don't guaranteed that getValue(docid) gets called in
order, though, and seems to require a value for every doc. We can
cheat on this, of course, but when I implemented this I preferred
skipping it entirely (see below).
- weighting... if a FunctionQuery is at the top level, we need a way
to get back un-weighted scores (actually, looking at the code again,
it looks like as long as the boost is 1, we will get back exact scores
from the FunctionQuery already).
Why do we need the unweighted score?
- Interface: seems like SOLR-334 (pluggable query parsers) could help
out here to enable existing handlers to specify a boosted query
without introducing yet more different (hard-coded) HTTP query params.
Thoughts?
I've implemented exactly this. see http://issues.apache.org/jira/
browse/LUCENE-850
Changed CustomScoreQuery (ValueSource-only) to CustomBoostQuery
(match/score query + arbitrary multiplicative boost query), and use
it with dismax (as an arbitrary number of bq.prod parameters) as
follows:
// generic product boost queries
List<Query> prodBoostQueries = U.parseQueryStrings(req,
params.getParams(DMP.BQ_PROD));
if (null != prodBoostQueries && prodBoostQueries.size() > 0) {
Query main = query;
Query out = null;
for(Query q: prodBoostQueries) {
out = new CustomBoostQuery(main, q);
main = out;
}
query = new BooleanQuery(true);
query.add(out, Occur.MUST);
}
-Mike
