NOTE: this API and implementation is subject to change suddenly in the next release.

EXPERIMENTAL API: This API is considered extremely advanced and experimental. It may be removed or altered w/o warning in future releases of Lucene.

Expert: Collectors are primarily meant to be used to gather raw results from a search, and implement sorting or custom result filtering, collation, etc.

As of 2.9, this class replaces the deprecated HitCollector, and offers an API for efficient collection of hits across sequential {@link IndexReader}s. {@link IndexSearcher} advances the collector through each of the sub readers, in an arbitrary order. This results in a higher performance means of collection.

Lucene's core collectors are derived from Collector. Likely your application can use one of these classes, or subclass {@link TopDocsCollector}, instead of implementing Collector directly:

• {@link TopDocsCollector} is an abstract base class that assumes you will retrieve the top N docs, according to some criteria, after collection is done.
• {@link TopScoreDocCollector} is a concrete subclass {@link TopDocsCollector} and sorts according to score + docID. This is used internally by the {@link IndexSearcher} search methods that do not take an explicit {@link Sort}. It is likely the most frequently used collector.
• {@link TopFieldCollector} subclasses {@link TopDocsCollector} and sorts according to a specified {@link Sort} object (sort by field). This is used internally by the {@link IndexSearcher} search methods that take an explicit {@link Sort}.
• {@link TimeLimitingCollector}, which wraps any other Collector and aborts the search if it's taken too much time, will subclass Collector in 3.0 (presently it subclasses the deprecated HitCollector).
• {@link PositiveScoresOnlyCollector} wraps any other Collector and prevents collection of hits whose score is <= 0.0

Collector decouples the score from the collected doc: the score computation is skipped entirely if it's not needed. Collectors that do need the score should implement the {@link #setScorer} method, to hold onto the passed {@link Scorer} instance, and call {@link Scorer#Score()} within the collect method to compute the current hit's score. If your collector may request the score for a single hit multiple times, you should use {@link ScoreCachingWrappingScorer}.

NOTE: The doc that is passed to the collect method is relative to the current reader. If your collector needs to resolve this to the docID space of the Multi*Reader, you must re-base it by recording the docBase from the most recent setNextReader call. Here's a simple example showing how to collect docIDs into a BitSet:

            Searcher searcher = new IndexSearcher(indexReader);
            final BitSet bits = new BitSet(indexReader.maxDoc());
            searcher.search(query, new Collector() {
            private int docBase;
            
            // ignore scorer
            public void setScorer(Scorer scorer) {
            }
            
            // accept docs out of order (for a BitSet it doesn't matter)
            public boolean acceptsDocsOutOfOrder() {
            return true;
            }
            
            public void collect(int doc) {
            bits.set(doc + docBase);
            }
            
            public void setNextReader(IndexReader reader, int docBase) {
            this.docBase = docBase;
            }
            });
            

Not all collectors will need to rebase the docID. For example, a collector that simply counts the total number of hits would skip it.

NOTE: Prior to 2.9, Lucene silently filtered out hits with score <= 0. As of 2.9, the core Collectors no longer do that. It's very unusual to have such hits (a negative query boost, or function query returning negative custom scores, could cause it to happen). If you need that behavior, use {@link PositiveScoresOnlyCollector}.

NOTE: This API is experimental and might change in incompatible ways in the next release.

It does not have an upper bound on the number of clauses covered in the range.

This query matches the documents looking for terms that fall into the supplied range according to {@link String#compareTo(String)}. It is not intended for numerical ranges, use {@link NumericRangeQuery} instead.

This query is hardwired to {@link MultiTermQuery#CONSTANT_SCORE_AUTO_REWRITE_DEFAULT}. If you want to change this, use {@link TermRangeQuery} instead.

Created: May 19, 2004 11:13:14 AM

NOTE: this API and implementation is subject to change suddenly in the next release.

FieldCacheRangeFilter builds a single cache for the field the first time it is used. Each subsequent FieldCacheRangeFilter on the same field then reuses this cache, even if the range itself changes.

This means that FieldCacheRangeFilter is much faster (sometimes more than 100x as fast) as building a {@link TermRangeFilter} (or {@link ConstantScoreRangeQuery} on a {@link TermRangeFilter}) for each query, if using a {@link #newStringRange}. However, if the range never changes it is slower (around 2x as slow) than building a CachingWrapperFilter on top of a single TermRangeFilter. For numeric data types, this filter may be significantly faster than {@link NumericRangeFilter}. Furthermore, it does not need the numeric values encoded by {@link NumericField}. But it has the problem that it only works with exact one value/document (see below).

As with all {@link FieldCache} based functionality, FieldCacheRangeFilter is only valid for fields which exact one term for each document (except for {@link #newStringRange} where 0 terms are also allowed). Due to a restriction of {@link FieldCache}, for numeric ranges all terms that do not have a numeric value, 0 is assumed.

Thus it works on dates, prices and other single value fields but will not work on regular text fields. It is preferable to use a

CopyC#

NOT_ANALYZED

This class does not have an constructor, use one of the static factory methods available, that create a correct instance for different data types supported by {@link FieldCache}.

This is the same functionality as TermsFilter (from contrib/queries), except this filter requires that the field contains only a single term for all documents. Because of drastically different implementations, they also have different performance characteristics, as described below.

The first invocation of this filter on a given field will be slower, since a {@link FieldCache.StringIndex} must be created. Subsequent invocations using the same field will re-use this cache. However, as with all functionality based on {@link FieldCache}, persistent RAM is consumed to hold the cache, and is not freed until the {@link IndexReader} is closed. In contrast, TermsFilter has no persistent RAM consumption.

With each search, this filter translates the specified set of Terms into a private {@link OpenBitSet} keyed by term number per unique {@link IndexReader} (normally one reader per segment). Then, during matching, the term number for each docID is retrieved from the cache and then checked for inclusion using the {@link OpenBitSet}. Since all testing is done using RAM resident data structures, performance should be very fast, most likely fast enough to not require further caching of the DocIdSet for each possible combination of terms. However, because docIDs are simply scanned linearly, an index with a great many small documents may find this linear scan too costly.

In contrast, TermsFilter builds up an {@link OpenBitSet}, keyed by docID, every time it's created, by enumerating through all matching docs using {@link TermDocs} to seek and scan through each term's docID list. While there is no linear scan of all docIDs, besides the allocation of the underlying array in the {@link OpenBitSet}, this approach requires a number of "disk seeks" in proportion to the number of terms, which can be exceptionally costly when there are cache misses in the OS's IO cache.

Generally, this filter will be slower on the first invocation for a given field, but subsequent invocations, even if you change the allowed set of Terms, should be faster than TermsFilter, especially as the number of Terms being matched increases. If you are matching only a very small number of terms, and those terms in turn match a very small number of documents, TermsFilter may perform faster.

Which filter is best is very application dependent.

This API is designed to achieve high performance sorting, by exposing a tight interaction with {@link FieldValueHitQueue} as it visits hits. Whenever a hit is competitive, it's enrolled into a virtual slot, which is an int ranging from 0 to numHits-1. The {@link FieldComparator} is made aware of segment transitions during searching in case any internal state it's tracking needs to be recomputed during these transitions.

A comparator must define these functions:

• {@link #compare} Compare a hit at 'slot a' with hit 'slot b'.
• {@link #setBottom} This method is called by {@link FieldValueHitQueue} to notify the FieldComparator of the current weakest ("bottom") slot. Note that this slot may not hold the weakest value according to your comparator, in cases where your comparator is not the primary one (ie, is only used to break ties from the comparators before it).
• {@link #compareBottom} Compare a new hit (docID) against the "weakest" (bottom) entry in the queue.
• {@link #copy} Installs a new hit into the priority queue. The {@link FieldValueHitQueue} calls this method when a new hit is competitive.
• {@link #setNextReader} Invoked when the search is switching to the next segment. You may need to update internal state of the comparator, for example retrieving new values from the {@link FieldCache}.
• {@link #value} Return the sort value stored in the specified slot. This is only called at the end of the search, in order to populate {@link FieldDoc#fields} when returning the top results.

CopyC#

fields

Created: Feb 11, 2004 1:23:38 PM

CopyC#

FieldCache.DEFAULT

Created: Dec 8, 2003 12:56:03 PM

Note: In Lucene 3.0 {@link #Bits(IndexReader)} will be removed and {@link #GetDocIdSet(IndexReader)} will be defined as abstract. All implementing classes must therefore implement {@link #GetDocIdSet(IndexReader)} in order to work with Lucene 3.0.

Technically, this same functionality could be achieved with ChainedFilter (under contrib/misc), however the benefit of this class is it never materializes the full bitset for the filter. Instead, the {@link #match} method is invoked on-demand, per docID visited during searching. If you know few docIDs will be visited, and the logic behind {@link #match} is relatively costly, this may be a better way to filter than ChainedFilter.

Note: the bits are retrieved from the filter each time this query is used in a search - use a CachingWrapperFilter to avoid regenerating the bits every time.

Created: Apr 20, 2004 8:58:29 AM

Term enumerations are always ordered by Term.compareTo(). Each term in the enumeration is greater than all that precede it.

Term enumerations are always ordered by Term.compareTo(). Each term in the enumeration is greater than all that precede it.

Caution: Iterate only over the hits needed. Iterating over all hits is generally not desirable and may be the source of performance issues. If you need to iterate over many or all hits, consider using the search method that takes a {@link HitCollector}.

Note: Deleting matching documents concurrently with traversing the hits, might, when deleting hits that were not yet retrieved, decrease {@link #Length()}. In such case, {@link java.util.ConcurrentModificationException ConcurrentModificationException} is thrown when accessing hit

CopyC#

n

CopyC#

n

Applications usually need only call the inherited {@link #Search(Query)} or {@link #Search(Query,Filter)} methods. For performance reasons it is recommended to open only one IndexSearcher and use it for all of your searches.

Note that you can only access Hits from an IndexSearcher as long as it is not yet closed, otherwise an IOException will be thrown.

NOTE: {@link

CopyC#

IndexSearcher

} instances are completely thread safe, meaning multiple threads can call any of its methods, concurrently. If your application requires external synchronization, you should not synchronize on the

CopyC#

IndexSearcher

instance; use your own (non-Lucene) objects instead.

CopyC#

Searchables

Applications usually need only call the inherited {@link #Search(Query)} or {@link #Search(Query,Filter)} methods.

This query cannot be used directly; you must subclass it and define {@link #getEnum} to provide a {@link FilteredTermEnum} that iterates through the terms to be matched.

NOTE: if {@link #setRewriteMethod} is either {@link #CONSTANT_SCORE_BOOLEAN_QUERY_REWRITE} or {@link #SCORING_BOOLEAN_QUERY_REWRITE}, you may encounter a {@link BooleanQuery.TooManyClauses} exception during searching, which happens when the number of terms to be searched exceeds {@link BooleanQuery#GetMaxClauseCount()}. Setting {@link #setRewriteMethod} to {@link #CONSTANT_SCORE_FILTER_REWRITE} prevents this.

The recommended rewrite method is {@link #CONSTANT_SCORE_AUTO_REWRITE_DEFAULT}: it doesn't spend CPU computing unhelpful scores, and it tries to pick the most performant rewrite method given the query. Note that {@link QueryParser} produces MultiTermQueries using {@link #CONSTANT_SCORE_AUTO_REWRITE_DEFAULT} by default.

CopyC#

MultiTermQueryWrapperFilter

For example, {@link TermRangeFilter} and {@link PrefixFilter} extend

CopyC#

MultiTermQueryWrapperFilter

You create a new NumericRangeFilter with the static factory methods, eg:

            Filter f = NumericRangeFilter.newFloatRange("weight",
            new Float(0.3f), new Float(0.10f),
            true, true);
            

NOTE: This API is experimental and might change in incompatible ways in the next release.

A {@link Query} that matches numeric values within a specified range. To use this, you must first index the numeric values using {@link NumericField} (expert: {@link NumericTokenStream}). If your terms are instead textual, you should use {@link TermRangeQuery}. {@link NumericRangeFilter} is the filter equivalent of this query.

You create a new NumericRangeQuery with the static factory methods, eg:

            Query q = NumericRangeQuery.newFloatRange("weight",
            new Float(0.3f), new Float(0.10f),
            true, true);
            

The performance of NumericRangeQuery is much better than the corresponding {@link TermRangeQuery} because the number of terms that must be searched is usually far fewer, thanks to trie indexing, described below.

You can optionally specify a

CopyC#

precisionStep

CopyC#

Numeric*

This query defaults to {@linkplain MultiTermQuery#CONSTANT_SCORE_AUTO_REWRITE_DEFAULT} for 32 bit (int/float) ranges with precisionStep <8 and 64 bit (long/double) ranges with precisionStep <6. Otherwise it uses {@linkplain MultiTermQuery#CONSTANT_SCORE_FILTER_REWRITE} as the number of terms is likely to be high. With precision steps of <4, this query can be run with one of the BooleanQuery rewrite methods without changing BooleanQuery's default max clause count.

NOTE: This API is experimental and might change in incompatible ways in the next release.

How it works

See the publication about panFMP, where this algorithm was described (referred to as

CopyC#

TrieRangeQuery

Schindler, U, Diepenbroek, M, 2008. Generic XML-based Framework for Metadata Portals. Computers & Geosciences 34 (12), 1947-1955. doi:10.1016/j.cageo.2008.02.023

A quote from this paper: Because Apache Lucene is a full-text search engine and not a conventional database, it cannot handle numerical ranges (e.g., field value is inside user defined bounds, even dates are numerical values). We have developed an extension to Apache Lucene that stores the numerical values in a special string-encoded format with variable precision (all numerical values like doubles, longs, floats, and ints are converted to lexicographic sortable string representations and stored with different precisions (for a more detailed description of how the values are stored, see {@link NumericUtils}). A range is then divided recursively into multiple intervals for searching: The center of the range is searched only with the lowest possible precision in the trie, while the boundaries are matched more exactly. This reduces the number of terms dramatically.

For the variant that stores long values in 8 different precisions (each reduced by 8 bits) that uses a lowest precision of 1 byte, the index contains only a maximum of 256 distinct values in the lowest precision. Overall, a range could consist of a theoretical maximum of

CopyC#

7*255*2 + 255 = 3825

Precision Step

You can choose any

CopyC#

precisionStep

when encoding values. Lower step values mean more precisions and so more terms in index (and index gets larger). On the other hand, the maximum number of terms to match reduces, which optimized query speed. The formula to calculate the maximum term count is:

            n = [ (bitsPerValue/precisionStep - 1) * (2^precisionStep - 1 ) * 2 ] + (2^precisionStep - 1 )
            

(this formula is only correct, when

CopyC#

bitsPerValue/precisionStep

is an integer; in other cases, the value must be rounded up and the last summand must contain the modulo of the division as precision step). For longs stored using a precision step of 4,

CopyC#

n = 15*15*2 + 15 = 465

, and for a precision step of 2,

CopyC#

n = 31*3*2 + 3 = 189

. But the faster search speed is reduced by more seeking in the term enum of the index. Because of this, the ideal

CopyC#

precisionStep

value can only be found out by testing. Important: You can index with a lower precision step value and test search speed using a multiple of the original step value.

Good values for

CopyC#

precisionStep

are depending on usage and data type:

• The default for all data types is 4, which is used, when no
  CopyC#

  precisionStep

  is given.
• Ideal value in most cases for 64 bit data types (long, double) is 6 or 8.
• Ideal value in most cases for 32 bit data types (int, float) is 4.
• Steps >64 for long/double and >32 for int/float produces one token per value in the index and querying is as slow as a conventional {@link TermRangeQuery}. But it can be used to produce fields, that are solely used for sorting (in this case simply use {@link Integer#MAX_VALUE} as
  CopyC#

  precisionStep

  ). Using {@link NumericField NumericFields} for sorting is ideal, because building the field cache is much faster than with text-only numbers. Sorting is also possible with range query optimized fields using one of the above
  CopyC#

  precisionSteps

  .

Comparisons of the different types of RangeQueries on an index with about 500,000 docs showed that {@link TermRangeQuery} in boolean rewrite mode (with raised {@link BooleanQuery} clause count) took about 30-40 secs to complete, {@link TermRangeQuery} in constant score filter rewrite mode took 5 secs and executing this class took <100ms to complete (on an Opteron64 machine, Java 1.5, 8 bit precision step). This query type was developed for a geographic portal, where the performance for e.g. bounding boxes or exact date/time stamps is important.

CopyC#

Searchables

Applications usually need only call the inherited {@link #Search(Query)} or {@link #Search(Query,Filter)} methods.

CopyC#

"new york"

This query may be combined with other terms or queries with a {@link BooleanQuery}.

CopyC#

app*

This query uses the {@link MultiTermQuery#CONSTANT_SCORE_AUTO_REWRITE_DEFAULT} rewrite method.

Term enumerations are always ordered by Term.compareTo(). Each term in the enumeration is greater than all that precede it.

Instantiable subclasses are:

• {@link TermQuery}
• {@link MultiTermQuery}
• {@link BooleanQuery}
• {@link WildcardQuery}
• {@link PhraseQuery}
• {@link PrefixQuery}
• {@link MultiPhraseQuery}
• {@link FuzzyQuery}
• {@link TermRangeQuery}
• {@link NumericRangeQuery}
• {@link Lucene.Net.Search.Spans.SpanQuery}

A parser for queries is contained in:

• {@link Lucene.Net.QueryParsers.QueryParser QueryParser}

This could be used, for example, with a {@link TermRangeQuery} on a suitably formatted date field to implement date filtering. One could re-use a single QueryFilter that matches, e.g., only documents modified within the last week. The QueryFilter and TermRangeQuery would only need to be reconstructed once per day.

This filter matches the documents looking for terms that fall into the supplied range according to {@link String#compareTo(String)}. It is not intended for numerical ranges, use {@link NumericRangeFilter} instead.

If you construct a large number of range filters with different ranges but on the same field, {@link FieldCacheRangeFilter} may have significantly better performance.

This query matches the documents looking for terms that fall into the supplied range according to {@link Term#CompareTo(Term)}. It is not intended for numerical ranges, use {@link NumericRangeQuery} instead.

This query uses {@linkplain MultiTermQuery#SCORING_BOOLEAN_QUERY_REWRITE}. If you want to change this, use the new {@link TermRangeQuery} instead.

A

CopyC#

Scorer

Document scores are computed using a given

CopyC#

Similarity

NOTE: The values Float.Nan, Float.NEGATIVE_INFINITY and Float.POSITIVE_INFINITY are not valid scores. Certain collectors (eg {@link TopScoreDocCollector}) will not properly collect hits with these scores.

Note that you can only access hits from a Searcher as long as it is not yet closed, otherwise an IOException will be thrown.

Subclasses implement search scoring.

The score of query

CopyC#

q

CopyC#

d

score(q,d)   =   coord(q,d)  ·  queryNorm(q)  ·  ∑ (tf(t in d)  ·  idf(t)2  ·  t.getBoost() ·  norm(t,d)) t in q

where

1. tf(t in d) correlates to the term's frequency, defined as the number of times term t appears in the currently scored document d. Documents that have more occurrences of a given term receive a higher score. The default computation for tf(t in d) in {@link Lucene.Net.Search.DefaultSimilarity#Tf(float) DefaultSimilarity} is:
    
   

   {@link Lucene.Net.Search.DefaultSimilarity#Tf(float) tf(t in d)}   =

   frequency½

   
    
   
2. idf(t) stands for Inverse Document Frequency. This value correlates to the inverse of docFreq (the number of documents in which the term t appears). This means rarer terms give higher contribution to the total score. The default computation for idf(t) in {@link Lucene.Net.Search.DefaultSimilarity#Idf(int, int) DefaultSimilarity} is:
    
   

   {@link Lucene.Net.Search.DefaultSimilarity#Idf(int, int) idf(t)}  =

   1 + log (

   numDocs ––––––––– docFreq+1

   )

   
    
   
3. coord(q,d) is a score factor based on how many of the query terms are found in the specified document. Typically, a document that contains more of the query's terms will receive a higher score than another document with fewer query terms. This is a search time factor computed in {@link #Coord(int, int) coord(q,d)} by the Similarity in effect at search time.
    
   
4. queryNorm(q) is a normalizing factor used to make scores between queries comparable. This factor does not affect document ranking (since all ranked documents are multiplied by the same factor), but rather just attempts to make scores from different queries (or even different indexes) comparable. This is a search time factor computed by the Similarity in effect at search time. The default computation in {@link Lucene.Net.Search.DefaultSimilarity#QueryNorm(float) DefaultSimilarity} is:
    
   

   queryNorm(q)   =   {@link Lucene.Net.Search.DefaultSimilarity#QueryNorm(float) queryNorm(sumOfSquaredWeights)}   =

   1 –––––––––––––– sumOfSquaredWeights½

   
    
   The sum of squared weights (of the query terms) is computed by the query {@link Lucene.Net.Search.Weight} object. For example, a {@link Lucene.Net.Search.BooleanQuery boolean query} computes this value as:
    
   

   {@link Lucene.Net.Search.Weight#SumOfSquaredWeights() sumOfSquaredWeights}   =   {@link Lucene.Net.Search.Query#GetBoost() q.getBoost()} 2  ·	∑	(idf(t)  ·  t.getBoost()) 2
   	t in q

   
    
   
5. t.getBoost() is a search time boost of term t in the query q as specified in the query text (see query syntax), or as set by application calls to {@link Lucene.Net.Search.Query#SetBoost(float) setBoost()}. Notice that there is really no direct API for accessing a boost of one term in a multi term query, but rather multi terms are represented in a query as multi {@link Lucene.Net.Search.TermQuery TermQuery} objects, and so the boost of a term in the query is accessible by calling the sub-query {@link Lucene.Net.Search.Query#GetBoost() getBoost()}.
    
   
6. norm(t,d) encapsulates a few (indexing time) boost and length factors:
   • Document boost - set by calling {@link Lucene.Net.Documents.Document#SetBoost(float) doc.setBoost()} before adding the document to the index.
   • Field boost - set by calling {@link Lucene.Net.Documents.Fieldable#SetBoost(float) field.setBoost()} before adding the field to a document.
   • {@link #LengthNorm(String, int) lengthNorm(field)} - computed when the document is added to the index in accordance with the number of tokens of this field in the document, so that shorter fields contribute more to the score. LengthNorm is computed by the Similarity class in effect at indexing.

   When a document is added to the index, all the above factors are multiplied. If the document has multiple fields with the same name, all their boosts are multiplied together:
    
   

   norm(t,d)   =   {@link Lucene.Net.Documents.Document#GetBoost() doc.getBoost()}  ·  {@link #LengthNorm(String, int) lengthNorm(field)}  ·	∏	{@link Lucene.Net.Documents.Fieldable#GetBoost() f.getBoost}()
   	field f in d named as t

   
    
   However the resulted norm value is {@link #EncodeNorm(float) encoded} as a single byte before being stored. At search time, the norm byte value is read from the index {@link Lucene.Net.Store.Directory directory} and {@link #DecodeNorm(byte) decoded} back to a float norm value. This encoding/decoding, while reducing index size, comes with the price of precision loss - it is not guaranteed that decode(encode(x)) = x. For instance, decode(encode(0.89)) = 0.75. Also notice that search time is too late to modify this norm part of scoring, e.g. by using a different {@link Similarity} for search.
    
   

The fields used to determine sort order must be carefully chosen. Documents must contain a single term in such a field, and the value of the term should indicate the document's relative position in a given sort order. The field must be indexed, but should not be tokenized, and does not need to be stored (unless you happen to want it back with the rest of your document data). In other words:

CopyC#

document.add (new Field ("byNumber", Integer.toString(x), Field.Store.NO, Field.Index.NOT_ANALYZED));

Valid Types of Values

There are four possible kinds of term values which may be put into sorting fields: Integers, Longs, Floats, or Strings. Unless {@link SortField SortField} objects are specified, the type of value in the field is determined by parsing the first term in the field.

Integer term values should contain only digits and an optional preceding negative sign. Values must be base 10 and in the range

CopyC#

Integer.MIN_VALUE

CopyC#

Integer.MAX_VALUE

CopyC#

1..n

CopyC#

1

CopyC#

n

Long term values should contain only digits and an optional preceding negative sign. Values must be base 10 and in the range

CopyC#

Long.MIN_VALUE

CopyC#

Long.MAX_VALUE

Float term values should conform to values accepted by {@link Float Float.valueOf(String)} (except that

CopyC#

NaN

CopyC#

Infinity

String term values can contain any valid String, but should not be tokenized. The values are sorted according to their {@link Comparable natural order}. Note that using this type of term value has higher memory requirements than the other two types.

Object Reuse

One of these objects can be used multiple times and the sort order changed between usages.

This class is thread safe.

Memory Usage

Sorting uses of caches of term values maintained by the internal HitQueue(s). The cache is static and contains an integer or float array of length

CopyC#

IndexReader.maxDoc()

CopyC#

4 * IndexReader.maxDoc() * (# of different fields actually used to sort)

For String fields, the cache is larger: in addition to the above array, the value of every term in the field is kept in memory. If there are many unique terms in the field, this could be quite large.

Note that the size of the cache is not affected by how many fields are in the index and might be used to sort - only by the ones actually used to sort a result set.

Created: Feb 12, 2004 10:53:57 AM

This class should only be used if the other SortField types (SCORE, DOC, STRING, INT, FLOAT) do not provide an adequate sorting. It maintains an internal cache of values which could be quite large. The cache is an array of Comparable, one for each document in the index. There is a distinct Comparable for each unique term in the field - if some documents have the same term in the field, the cache array will have entries which reference the same Comparable. This class will be used as part of a key to a FieldCache value. You must implement hashCode and equals to avoid an explosion in RAM usage if you use instances that are not the same instance. If you are searching using the Remote contrib, the same instance of this class on the client will be a new instance on every call to the server, so hashCode/equals is very important in that situation.

Created: Apr 21, 2004 5:08:38 PM

Created: Feb 11, 2004 1:25:29 PM

NOTE: This API is still experimental and subject to change.

This filter does not cache. See the {@link Lucene.Net.Search.CachingSpanFilter} for a wrapper that caches.

This filter matches the documents looking for terms that fall into the supplied range according to {@link String#compareTo(String)}. It is not intended for numerical ranges, use {@link NumericRangeFilter} instead.

If you construct a large number of range filters with different ranges but on the same field, {@link FieldCacheRangeFilter} may have significantly better performance.

This query matches the documents looking for terms that fall into the supplied range according to {@link String#compareTo(String)}. It is not intended for numerical ranges, use {@link NumericRangeQuery} instead.

This query uses the {@link MultiTermQuery#CONSTANT_SCORE_AUTO_REWRITE_DEFAULT} rewrite method.

Term enumerations are always ordered by Term.compareTo(). Each term in the enumeration is greater than all that precede it.

The TimeLimitedCollector is used to timeout search requests that take longer than the maximum allowed search time limit. After this time is exceeded, the search thread is stopped by throwing a TimeExceeded Exception.

This may be extended, overriding the collect method to, e.g., conditionally invoke

CopyC#

super()

See the {@link #create(Lucene.Net.Search.Sort, int, boolean, boolean, boolean, boolean)} method for instantiating a TopFieldCollector.

NOTE: This API is experimental and might change in incompatible ways in the next release.

This may be extended, overriding the collect method to, e.g., conditionally invoke

CopyC#

super()

NOTE: The values {@link Float#NaN} and {Float#NEGATIVE_INFINITY} are not valid scores. This collector will not properly collect hits with such scores.

The purpose of {@link Weight} is to ensure searching does not modify a {@link Query}, so that a {@link Query} instance can be reused.
{@link Searcher} dependent state of the query should reside in the {@link Weight}.
{@link IndexReader} dependent state should reside in the {@link Scorer}.

A

CopyC#

Weight

1. A
   CopyC#

   Weight

   is constructed by a top-level query, given a
   CopyC#

   Searcher

   ({@link Query#CreateWeight(Searcher)}).
2. The {@link #SumOfSquaredWeights()} method is called on the
   CopyC#

   Weight

   to compute the query normalization factor {@link Similarity#QueryNorm(float)} of the query clauses contained in the query.
3. The query normalization factor is passed to {@link #Normalize(float)}. At this point the weighting is complete.
4. A
   CopyC#

   Scorer

   is constructed by {@link #Scorer(IndexReader,boolean,boolean)}.

CopyC#

*

CopyC#

?

CopyC#

*

CopyC#

?

This query uses the {@link MultiTermQuery#CONSTANT_SCORE_AUTO_REWRITE_DEFAULT} rewrite method.

Term enumerations are always ordered by Term.compareTo(). Each term in the enumeration is greater than all that precede it.

Created: Feb 3, 2004 9:00:16 AM

Searchable is the abstract network protocol for searching. Implementations provide search over a single index, over multiple indices, and over indices on remote servers.

Queries, filters and sort criteria are designed to be compact so that they may be efficiently passed to a remote index, with only the top-scoring hits being returned, rather than every matching hit. NOTE: this interface is kept public for convenience. Since it is not expected to be implemented directly, it may be changed unexpectedly between releases.

Created: Apr 21, 2004 3:49:28 PM This class will be used as part of a key to a FieldCache value. You must implement hashCode and equals to avoid an explosion in RAM usage if you use instances that are not the same instance. If you are searching using the Remote contrib, the same instance of this class on the client will be a new instance on every call to the server, so hashCode/equals is very important in that situation.