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

class	CustomScoreProvider
	An instance of this subclass should be returned by CustomScoreQuery.GetCustomScoreProvider, if you want to modify the custom score calculation of a CustomScoreQuery. More...

class	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 FieldScoreQuery Subclasses can modify the computation by overriding GetCustomScoreProvider. More...

class	DocValues
	Expert: represents field values as different types. Normally created via a ValueSuorce for a particular field and reader. More...

class	FieldCacheSource
	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. More...

class	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: Type.BYTE consumes 1 * maxDocs bytes. Type.SHORT consumes 2 * maxDocs bytes. Type.INT consumes 4 * maxDocs bytes. 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! More...

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

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

class	OrdFieldSource
	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. More...

class	ReverseOrdFieldSource
	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. More...

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

class	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 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. More...

class	ValueSourceQuery
	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). More...

Classes