Short answer: the existence is entirely historic. I added bq because i
needed it, and then i added bf because the _val_:"..." syntax was anoying.
: can't think of a useful case when I want to both *add* a component to
: the ultimate score, and for that component to be a non-function query
: (i.e. use the lucene query parser).
one of the original use cases for bq was for artificial keyword boosting,
in which case it still comes in handy...
bq=meta:promote^100 text:new^10 category:featured^100 (*:*
-category:accessories)^10
: Also, you can basically get the same affect as a boost query via boost
: functions: bf=query(mybq)&mybq=... and note you will probably multiply
: this via product(10,query(mybq)) to boost it to an appropriate number.
the "boost" param of edismax is probably a lot better choice then either
bq/bf -- but it really depends on wether you want an additive boost or a
multiplicitive one (of course with teh function query syntax add(),
product() and (query() can be combined in anyway you want)
in terms of the merrits of the bq vs bf, if we wanted to get rid of one or
the other, i'd argue eliminating bf since it has *very* brittle parsing
rules in place (for historic reasons). while you can use variable
derefrencing to get the "guts" of either a bf=query($a) or a bq={$func
v=$a}, promoting the use of bq over bf makes using the param body inline
simpler so people are less likely to run into problems (ie: bq={!func}...
doesn't require any special escaping, but bf=query(...) does)
-Hoss
