Namespace Lucene.Net.Search.Function

Expert: obtains single byte field values from the FieldCache using getBytes() and makes those values available as other numeric types, casting as needed.

WARNING: The status of the Search.Function package is experimental. The APIs introduced here might change in the future and will not be supported anymore in such a case.

An instance of this subclass should be returned by GetCustomScoreProvider(IndexReader), if you want to modify the custom score calculation of a CustomScoreQuery.

Since Lucene 2.9, queries operate on each segment of an Index separately, so overriding the similar (now deprecated) methods in CustomScoreQuery is no longer suitable, as the supplied doc ID is per-segment and without knowledge of the IndexReader you cannot access the document or FieldCache.

@lucene.experimental @since 2.9.2

Query that sets document score as a programmatic function of several (sub) scores:

WARNING: The status of the Search.Function package is experimental. The APIs introduced here might change in the future and will not be supported anymore in such a case.

Expert: represents field values as different types. Normally created via a ValueSource for a particular field and reader.

WARNING: The status of the Search.Function package is experimental. The APIs introduced here might change in the future and will not be supported anymore in such a case.

Expert: A base class for ValueSource implementations that retrieve values for a single field from the FieldCache.

Fields used herein nust be indexed (doesn't matter if these fields are stored or not).

It is assumed that each such indexed field is untokenized, or at least has a single token in a document. For documents with multiple tokens of the same field, behavior is undefined (It is likely that current code would use the value of one of these tokens, but this is not guaranteed).

Document with no tokens in this field are assigned the Zero value.

WARNING: The status of the Search.Function package is experimental. The APIs introduced here might change in the future and will not be supported anymore in such a case.

NOTE: with the switch in 2.9 to segment-based searching, if GetValues(IndexReader) is invoked with a composite (multi-segment) reader, this can easily cause double RAM usage for the values in the FieldCache. It's best to switch your application to pass only atomic (single segment) readers to this API.

A query that scores each document as the value of the numeric input field.

The query matches all documents, and scores each document according to the numeric value of that field.

It is assumed, and expected, that:

Combining this query in a FunctionQuery allows much freedom in affecting document scores. Note, that with this freedom comes responsibility: it is more than likely that the default Lucene scoring is superior in quality to scoring modified as explained here. However, in some cases, and certainly for research experiments, this capability may turn useful.

When contructing this query, select the appropriate type. That type should match the data stored in the field. So in fact the "right" type should be selected before indexing. Type selection has effect on the RAM usage:

Caching: Values for the numeric field are loaded once and cached in memory for further use with the same IndexReader. To take advantage of this, it is extremely important to reuse index-readers or index-searchers, otherwise, for instance if for each query a new index reader is opened, large penalties would be paid for loading the field values into memory over and over again!

WARNING: The status of the Search.Function package is experimental. The APIs introduced here might change in the future and will not be supported anymore in such a case.

Type of score field, indicating how field values are interpreted/parsed.

The type selected at search search time should match the data stored in the field. Different types have different RAM requirements:

Expert: obtains float field values from the FieldCache using getFloats() and makes those values available as other numeric types, casting as needed.

WARNING: The status of the Search.Function package is experimental. The APIs introduced here might change in the future and will not be supported anymore in such a case.

Expert: obtains int field values from the FieldCache using getInts() and makes those values available as other numeric types, casting as needed.

WARNING: The status of the Search.Function package is experimental. The APIs introduced here might change in the future and will not be supported anymore in such a case.

Expert: obtains the ordinal of the field value from the default Lucene FieldCache using getStringIndex().

The native lucene index order is used to assign an ordinal value for each field value.

Field values (terms) are lexicographically ordered by unicode value, and numbered starting at 1.

Example:
If there were only three field values: "apple","banana","pear"
then ord("apple")=1, ord("banana")=2, ord("pear")=3

WARNING: ord() depends on the position in an index and can thus change when other documents are inserted or deleted, or if a MultiSearcher is used.

WARNING: The status of the Search.Function package is experimental. The APIs introduced here might change in the future and will not be supported anymore in such a case.

NOTE: with the switch in 2.9 to segment-based searching, if GetValues(IndexReader) is invoked with a composite (multi-segment) reader, this can easily cause double RAM usage for the values in the FieldCache. It's best to switch your application to pass only atomic (single segment) readers to this API.

Expert: obtains the ordinal of the field value from the default Lucene FieldCache using getStringIndex() and reverses the order.

The native lucene index order is used to assign an ordinal value for each field value.

Field values (terms) are lexicographically ordered by unicode value, and numbered starting at 1.
Example of reverse ordinal (rord):
If there were only three field values: "apple","banana","pear"
then rord("apple")=3, rord("banana")=2, ord("pear")=1

WARNING: rord() depends on the position in an index and can thus change when other documents are inserted or deleted, or if a MultiSearcher is used.

WARNING: The status of the Search.Function package is experimental. The APIs introduced here might change in the future and will not be supported anymore in such a case.

NOTE: with the switch in 2.9 to segment-based searching, if GetValues(IndexReader) is invoked with a composite (multi-segment) reader, this can easily cause double RAM usage for the values in the FieldCache. It's best to switch your application to pass only atomic (single segment) readers to this API.

Expert: obtains short field values from the FieldCache using getShorts() and makes those values available as other numeric types, casting as needed.

WARNING: The status of the Search.Function package is experimental. The APIs introduced here might change in the future and will not be supported anymore in such a case.

Expert: source of values for basic function queries.

At its default/simplest form, values - one per doc - are used as the score of that doc.

Values are instantiated as DocValues for a particular reader.

ValueSource implementations differ in RAM requirements: it would always be a factor of the number of documents, but for each document the number of bytes can be 1, 2, 4, or 8.

WARNING: The status of the Search.Function package is experimental. The APIs introduced here might change in the future and will not be supported anymore in such a case.

Expert: A Query that sets the scores of document to the values obtained from a ValueSource.

This query provides a score for each and every undeleted document in the index.

The value source can be based on a (cached) value of an indexed field, but it can also be based on an external source, e.g. values read from an external database.

Score is set as: Score(doc,query) = query.getBoost()² * valueSource(doc).

WARNING: The status of the Search.Function package is experimental. The APIs introduced here might change in the future and will not be supported anymore in such a case.