: I would love to know when it is okay to return a ConstantScoreQuery
: wrapping my Filter so that I needn't bother with my ValueSource. In my
: opinion, FieldType should have a getFieldFilter() method similar to
: getFieldQuery(). Perhaps a hint of some kind could be added to the
: QParser handed in -- a boolean flag or some special local-param to
: indicate the constant score to use. Solr could perform this when the
: QParser is constructed for a Filter Query.
my gut raction is that this seems like it could be dangerous in the
general case -- it could lead to subtle bugs where a FieldType might
inadvertantly produce a query that matches different documents depending
on context (doesn't mean we shouldn't do it, just a risk i worry about)
if we do go this route, adding it as a hint on the QParser seems like a
cleaner appraoch then a completely new method on FieldType (particularly
because then generic QParsers might be able to leverage this info as well
... consider fq={!geofilt ... } vs q={!geofilt ... }).
As a first pass i would suggest that your FieldType could do this kind of
logic as is right now by reqiring a special param (local or otherwise),
something like...
fq={!field needScore=false f=yourSpecialField}foo
...where your field type has...
public Query getFieldQuery(QParser parser, SchemaField field, String
externalVal)
Filter f = makeFilter(...);
if (parser.getLocalParams().getBool("needScore", true)) {
ValueSource vs = makeValueSource(...);
uses memory
return new FilteredQuery( new FunctionQuery(vs), f );
}
return new ConstantScoreQuery(f);
}
...in general this type of explicit approach (based on a param) is
apealing because it would help mitigate the risk i mentioned about queries
matching diff docs being (accidently?) produced depending on context --
much easier to spot/understand if the query changes if-and-only-if a param
changes.
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
