[Missing <summary> documentation for "N:Lucene.Net.Search.Function"]

Classes

	Class	Description
	ByteFieldSource	Expert: obtains single byte field values from the {@link Lucene.Net.Search.FieldCache FieldCache} using CopyC# 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.
	CustomScoreProvider
	CustomScoreQuery	Query that sets document score as a programmatic function of several (sub) scores: the score of its subQuery (any query) (optional) the score of its ValueSourceQuery (or queries). For most simple/convenient use cases this query is likely to be a {@link Lucene.Net.Search.Function.FieldScoreQuery FieldScoreQuery} Subclasses can modify the computation by overriding {@link #getCustomScoreProvider}. 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.
	DocValues	Expert: represents field values as different types. Normally created via a {@link Lucene.Net.Search.Function.ValueSource ValueSuorce} 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.
	FieldCacheSource	Expert: A base class for ValueSource implementations that retrieve values for a single field from the {@link Lucene.Net.Search.FieldCache 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 CopyC# 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 {@link #getValues} 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. Alternatively, for a short-term fix, you could wrap your ValueSource using {@link MultiValueSource}, which costs more CPU per lookup but will not consume double the FieldCache RAM.
	FieldScoreQuery	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: The field used here is indexed, and has exactly one token in every scored document. Best if this field is un_tokenized. That token is parsable to the selected type. 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: {@link Type#BYTE} consumes 1 * maxDocs bytes. {@link Type#SHORT} consumes 2 * maxDocs bytes. {@link Type#INT} consumes 4 * maxDocs bytes. {@link Type#FLOAT} consumes 8 * maxDocs bytes. 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.
	FieldScoreQuery..::..Type	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: {@link #BYTE} consumes 1 * maxDocs bytes. {@link #SHORT} consumes 2 * maxDocs bytes. {@link #INT} consumes 4 * maxDocs bytes. {@link #FLOAT} consumes 8 * maxDocs bytes.
	FloatFieldSource	Expert: obtains float field values from the {@link Lucene.Net.Search.FieldCache FieldCache} using CopyC# 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.
	IntFieldSource	Expert: obtains int field values from the {@link Lucene.Net.Search.FieldCache FieldCache} using CopyC# 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.
	MultiValueSource	Obsolete. This class wraps another ValueSource, but protects against accidental double RAM usage in FieldCache when a composite reader is passed to {@link #getValues}. NOTE: this class adds a CPU penalty to every lookup, as it must resolve the incoming document to the right sub-reader using a binary search.
	OrdFieldSource	Expert: obtains the ordinal of the field value from the default Lucene {@link Lucene.Net.Search.FieldCache 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 {@link #getValues} 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. Alternatively, for a short-term fix, you could wrap your ValueSource using {@link MultiValueSource}, which costs more CPU per lookup but will not consume double the FieldCache RAM.
	ReverseOrdFieldSource	Expert: obtains the ordinal of the field value from the default Lucene {@link Lucene.Net.Search.FieldCache 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 {@link #getValues} 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. Alternatively, for a short-term fix, you could wrap your ValueSource using {@link MultiValueSource}, which costs more CPU per lookup but will not consume double the FieldCache RAM.
	ShortFieldSource	Expert: obtains short field values from the {@link Lucene.Net.Search.FieldCache FieldCache} using CopyC# 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.
	ValueSource	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 {@link Lucene.Net.Search.Function.DocValues 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.
	ValueSourceQuery	Expert: A Query that sets the scores of document to the values obtained from a {@link Lucene.Net.Search.Function.ValueSource 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.