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

Classes

  ClassDescription
Public classBooleanClause
A clause in a BooleanQuery.
Public classBooleanClause..::..Occur
Specifies how clauses are to occur in matching documents.
Public classBooleanFilter
Public classBooleanFilterClause
A spefic clause that makes up a part of the BooleanFilter
Public classBooleanQuery
A Query that matches documents matching boolean combinations of other queries, e.g. {@link TermQuery}s, {@link PhraseQuery}s or other BooleanQuerys.
Protected classBooleanQuery..::..BooleanWeight
Expert: the Weight for BooleanQuery, used to normalize, score and explain these queries.

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

Public classBooleanQuery..::..TooManyClauses
Thrown when an attempt is made to add more than {@link #GetMaxClauseCount()} clauses. This typically happens if a PrefixQuery, FuzzyQuery, WildcardQuery, or TermRangeQuery is expanded to many terms during search.
Public classBooleanScorer
Public classBoostingQuery
Public classCacheEntry
EXPERT: A unique Identifier/Description for each item in the FieldCache. Can be useful for logging/debugging.

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

Public classCachingSpanFilter
Wraps another SpanFilter's result and caches it. The purpose is to allow filters to simply filter, and then wrap with this class to add caching.
Public classCachingWrapperFilter
Wraps another filter's result and caches it. The purpose is to allow filters to simply filter, and then wrap with this class to add caching.
Public classCachingWrapperFilter..::..DeletesMode
Public classCollector

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.

Public classComplexExplanation
Expert: Describes the score computation for document and query, and can distinguish a match independent of a positive value.
Public classConstantScoreQuery
A query that wraps a filter and simply returns a constant score equal to the query boost for every document in the filter.
Protected classConstantScoreQuery..::..ConstantScorer
Protected classConstantScoreQuery..::..ConstantWeight
Public classConstantScoreRangeQuery Obsolete.
A range query that returns a constant score equal to its boost for all documents in the exclusive range of terms.

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.

Public classCreationPlaceholder
Expert: Maintains caches of term values.

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

Public classDefaultSimilarity
Expert: Default scoring implementation.
Public classDisjunctionMaxQuery
A query that generates the union of documents produced by its subqueries, and that scores each document with the maximum score for that document as produced by any subquery, plus a tie breaking increment for any additional matching subqueries. This is useful when searching for a word in multiple fields with different boost factors (so that the fields cannot be combined equivalently into a single search field). We want the primary score to be the one associated with the highest boost, not the sum of the field scores (as BooleanQuery would give). If the query is "albino elephant" this ensures that "albino" matching one field and "elephant" matching another gets a higher score than "albino" matching both fields. To get this result, use both BooleanQuery and DisjunctionMaxQuery: for each term a DisjunctionMaxQuery searches for it in each field, while the set of these DisjunctionMaxQuery's is combined into a BooleanQuery. The tie breaker capability allows results that include the same term in multiple fields to be judged better than results that include this term in only the best of those multiple fields, without confusing this with the better case of two different terms in the multiple fields.
Protected classDisjunctionMaxQuery..::..DisjunctionMaxWeight
Expert: the Weight for DisjunctionMaxQuery, used to normalize, score and explain these queries.

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

Public classDocIdSet
A DocIdSet contains a set of doc ids. Implementing classes must only implement {@link #iterator} to provide access to the set.
Public classDocIdSet..::..AnonymousClassDocIdSet
Public classDocIdSet..::..AnonymousClassDocIdSet..::..AnonymousClassDocIdSetIterator
Public classDocIdSetIterator
This abstract class defines methods to iterate over a set of non-decreasing doc ids. Note that this class assumes it iterates on doc Ids, and therefore {@link #NO_MORE_DOCS} is set to {@value #NO_MORE_DOCS} in order to be used as a sentinel object. Implementations of this class are expected to consider {@link Integer#MAX_VALUE} as an invalid value.
Public classDuplicateFilter
Public classExplanation
Expert: Describes the score computation for document and query.
Public classExplanation..::..IDFExplanation
Small Util class used to pass both an idf factor as well as an explanation for that factor. This class will likely be held on a {@link Weight}, so be aware before storing any large or un-serializable fields.
Public classExtensions
Public classFieldCacheRangeFilter
A range filter built on top of a cached single term field (in {@link FieldCache}).

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
field to ensure that there is only a single term.

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}.

Public classFieldCacheTermsFilter
A {@link Filter} that only accepts documents whose single term value in the specified field is contained in the provided set of allowed terms.

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.

Protected classFieldCacheTermsFilter..::..FieldCacheTermsFilterDocIdSet
Protected classFieldCacheTermsFilter..::..FieldCacheTermsFilterDocIdSet..::..FieldCacheTermsFilterDocIdSetIterator
Public classFieldComparator
Expert: a FieldComparator compares hits so as to determine their sort order when collecting the top results with {@link TopFieldCollector}. The concrete public FieldComparator classes here correspond to the SortField types.

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.
NOTE: This API is experimental and might change in incompatible ways in the next release.
Public classFieldComparator..::..ByteComparator
Parses field's values as byte (using {@link FieldCache#getBytes} and sorts by ascending value
Public classFieldComparator..::..DocComparator
Sorts by ascending docID
Public classFieldComparator..::..DoubleComparator
Parses field's values as double (using {@link FieldCache#getDoubles} and sorts by ascending value
Public classFieldComparator..::..FloatComparator
Parses field's values as float (using {@link FieldCache#getFloats} and sorts by ascending value
Public classFieldComparator..::..IntComparator
Parses field's values as int (using {@link FieldCache#getInts} and sorts by ascending value
Public classFieldComparator..::..LongComparator
Parses field's values as long (using {@link FieldCache#getLongs} and sorts by ascending value
Public classFieldComparator..::..RelevanceComparator
Sorts by descending relevance. NOTE: if you are sorting only by descending relevance and then secondarily by ascending docID, peformance is faster using {@link TopScoreDocCollector} directly (which {@link IndexSearcher#search} uses when no {@link Sort} is specified).
Public classFieldComparator..::..ShortComparator
Parses field's values as short (using {@link FieldCache#getShorts} and sorts by ascending value
Public classFieldComparator..::..StringComparatorLocale
Sorts by a field's value using the Collator for a given Locale.
Public classFieldComparator..::..StringOrdValComparator
Sorts by field's natural String sort order, using ordinals. This is functionally equivalent to {@link StringValComparator}, but it first resolves the string to their relative ordinal positions (using the index returned by {@link FieldCache#getStringIndex}), and does most comparisons using the ordinals. For medium to large results, this comparator will be much faster than {@link StringValComparator}. For very small result sets it may be slower.
Public classFieldComparator..::..StringValComparator
Sorts by field's natural String sort order. All comparisons are done using String.compareTo, which is slow for medium to large result sets but possibly very fast for very small results sets.
Public classFieldComparatorSource
Provides a {@link FieldComparator} for custom field sorting. NOTE: This API is experimental and might change in incompatible ways in the next release.
Public classFieldDoc
Expert: A ScoreDoc which also contains information about how to sort the referenced document. In addition to the document number and score, this object contains an array of values for the document from the field(s) used to sort. For example, if the sort criteria was to sort by fields "a", "b" then "c", the
CopyC#
fields
object array will have three elements, corresponding respectively to the term values for the document in fields "a", "b" and "c". The class of each element in the array will be either Integer, Float or String depending on the type of values in the terms of each field.

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

Public classFieldSortedHitQueue Obsolete.
Expert: A hit queue for sorting by hits by terms in more than one field. Uses
CopyC#
FieldCache.DEFAULT
for maintaining internal term lookup tables.

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

Public classFieldValueHitQueue
Expert: A hit queue for sorting by hits by terms in more than one field. Uses
CopyC#
FieldCache.DEFAULT
for maintaining internal term lookup tables. This class will not resolve SortField.AUTO types, and expects the type of all SortFields used for construction to already have been resolved. {@link SortField#DetectFieldType(IndexReader, String)} is a utility method which may be used for field type detection. NOTE: This API is experimental and might change in incompatible ways in the next release.
Public classFilter
Abstract base class for restricting which documents may be returned during searching.

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.

Public classFilteredDocIdSet
Abstract decorator class for a DocIdSet implementation that provides on-demand filtering/validation mechanism on a given DocIdSet.

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.

Public classFilteredDocIdSetIterator
Abstract decorator class of a DocIdSetIterator implementation that provides on-demand filter/validation mechanism on an underlying DocIdSetIterator. See {@link FilteredDocIdSet}.
Public classFilteredQuery
A query that applies a filter to the results of another query.

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

Public classFilteredTermEnum
Abstract class for enumerating a subset of all terms.

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

Public classFilterManager
Filter caching singleton. It can be used to save filters locally for reuse. This class makes it possble to cache Filters even when using RMI, as it keeps the cache on the seaercher side of the RMI connection. Also could be used as a persistent storage for any filter as long as the filter provides a proper hashCode(), as that is used as the key in the cache. The cache is periodically cleaned up from a separate thread to ensure the cache doesn't exceed the maximum size.
Protected classFilterManager..::..FilterCleaner
Keeps the cache from getting too big. If we were using Java 1.5, we could use LinkedHashMap and we would not need this thread to clean out the cache. The SortedSet sortedFilterItems is used only to sort the items from the cache, so when it's time to clean up we have the TreeSet sort the FilterItems by timestamp. Removes 1.5 * the numbers of items to make the cache smaller. For example: If cache clean size is 10, and the cache is at 15, we would remove (15 - 10) * 1.5 = 7.5 round up to 8. This way we clean the cache a bit more, and avoid having the cache cleaner having to do it frequently.
Protected classFilterManager..::..FilterItem
Holds the filter and the last time the filter was used, to make LRU-based cache cleaning possible. TODO: Clean this up when we switch to Java 1.5
Public classFuzzyLikeThisQuery
Fuzzifies ALL terms provided as strings and then picks the best n differentiating terms. In effect this mixes the behaviour of FuzzyQuery and MoreLikeThis but with special consideration of fuzzy scoring factors. This generally produces good results for queries where users may provide details in a number of fields and have no knowledge of boolean query syntax and also want a degree of fuzzy matching and a fast query. For each source term the fuzzy variants are held in a BooleanQuery with no coord factor (because we are not looking for matches on multiple variants in any one doc). Additionally, a specialized TermQuery is used for variants and does not use that variant term's IDF because this would favour rarer terms eg misspellings. Instead, all variants use the same IDF ranking (the one for the source query term) and this is factored into the variant's boost. If the source query term does not exist in the index the average IDF of the variants is used.
Public classFuzzyQuery
Implements the fuzzy search query. The similarity measurement is based on the Levenshtein (edit distance) algorithm. Warning: this query is not very scalable with its default prefix length of 0 - in this case, *every* term will be enumerated and cause an edit score calculation.
Protected classFuzzyQuery..::..ScoreTerm
Protected classFuzzyQuery..::..ScoreTermQueue
Public classFuzzyTermEnum
Subclass of FilteredTermEnum for enumerating all terms that are similiar to the specified filter term.

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

Public classHit Obsolete.
Wrapper used by {@link HitIterator} to provide a lazily loaded hit from {@link Hits}.
Public classHitCollector Obsolete.
Lower-level search API.
HitCollectors are primarily meant to be used to implement queries, sorting and filtering. See {@link Collector} for a lower level and higher performance (on a multi-segment index) API.
Public classHitCollectorWrapper Obsolete.
Wrapper for ({@link HitCollector}) implementations, which simply re-bases the incoming docID before calling {@link HitCollector#collect}.
Public classHitIterator Obsolete.
An iterator over {@link Hits} that provides lazy fetching of each document. {@link Hits#Iterator()} returns an instance of this class. Calls to {@link #next()} return a {@link Hit} instance.
Public classHitQueue
Public classHits Obsolete.
A ranked list of documents, used to hold search results.

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
> current_{@link #Length()} (but
CopyC#
n
< {@link #Length()} _at_start).
Public classIndexSearcher
Implements search over a single IndexReader.

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

} 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.

Public classMatchAllDocsQuery
A query that matches all documents.
Public classMultiPhraseQuery
MultiPhraseQuery is a generalized version of PhraseQuery, with an added method {@link #Add(Term[])}. To use this class, to search for the phrase "Microsoft app*" first use add(Term) on the term "Microsoft", then find all terms that have "app" as prefix using IndexReader.terms(Term), and use MultiPhraseQuery.add(Term[] terms) to add them to the query.
Public classMultiSearcher
Implements search over a set of
CopyC#
Searchables
.

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

Public classMultiTermQuery
An abstract {@link Query} that matches documents containing a subset of terms provided by a {@link FilteredTermEnum} enumeration.

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.

Public classMultiTermQuery..::..AnonymousClassConstantScoreAutoRewrite
Public classMultiTermQuery..::..ConstantScoreAutoRewrite
A rewrite method that tries to pick the best constant-score rewrite method based on term and document counts from the query. If both the number of terms and documents is small enough, then {@link #CONSTANT_SCORE_BOOLEAN_QUERY_REWRITE} is used. Otherwise, {@link #CONSTANT_SCORE_FILTER_REWRITE} is used.
Public classMultiTermQuery..::..RewriteMethod
Abstract class that defines how the query is rewritten.
Public classMultiTermQueryWrapperFilter
A wrapper for {@link MultiTermQuery}, that exposes its functionality as a {@link Filter}.

CopyC#
MultiTermQueryWrapperFilter
is not designed to be used by itself. Normally you subclass it to provide a Filter counterpart for a {@link MultiTermQuery} subclass.

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

CopyC#
MultiTermQueryWrapperFilter
. This class also provides the functionality behind {@link MultiTermQuery#CONSTANT_SCORE_FILTER_REWRITE}; this is why it is not abstract.
Public classNumericRangeFilter
A {@link Filter} that only accepts numeric values within a specified range. To use this, you must first index the numeric values using {@link NumericField} (expert: {@link NumericTokenStream}).

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);
            
accepts all documents whose float valued "weight" field ranges from 0.3 to 0.10, inclusive. See {@link NumericRangeQuery} for details on how Lucene indexes and searches numeric valued fields.

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

Public classNumericRangeQuery

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);
            
matches all documents whose float valued "weight" field ranges from 0.3 to 0.10, inclusive.

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

when creating this query. This is necessary if you've changed this configuration from its default (4) during indexing. Lower values consume more disk space but speed up searching. Suitable values are between 1 and 8. A good starting point to test is 4, which is the default value for all
CopyC#
Numeric*
classes. See below for details.

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
distinct terms (when there is a term for every distinct value of an 8-byte-number in the index and the range covers almost all of them; a maximum of 255 distinct values is used because it would always be possible to reduce the full 256 values to one term with degraded precision). In practice, we have seen up to 300 terms in most cases (index with 500,000 metadata records and a uniform value distribution).

Precision Step

You can choose any

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.

Public classParallelMultiSearcher
Implements parallel search over a set of
CopyC#
Searchables
.

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

Public classPhraseQuery
A Query that matches documents containing a particular sequence of terms. A PhraseQuery is built by QueryParser for input like
CopyC#
"new york"
.

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

Public classPositiveScoresOnlyCollector
A {@link Collector} implementation which wraps another {@link Collector} and makes sure only documents with scores > 0 are collected.
Public classPrefixFilter
A Filter that restricts search results to values that have a matching prefix in a given field.
Public classPrefixQuery
A Query that matches documents containing terms with a specified prefix. A PrefixQuery is built by QueryParser for input like
CopyC#
app*
.

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

Public classPrefixTermEnum
Subclass of FilteredTermEnum for enumerating all terms that match the specified prefix filter term.

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

Public classQuery
The abstract base class for queries.

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}
Public classQueryFilter Obsolete.
Constrains search results to only match those which also match a provided query. Results are cached, so that searches after the first on the same index using this filter are much faster.
Public classQueryTermVector
Public classQueryWrapperFilter
Constrains search results to only match those which also match a provided query.

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.

Public classRangeFilter Obsolete.
A Filter that restricts search results to a range of values in a given field.

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.

Public classRangeQuery Obsolete.
A Query that matches documents within an exclusive range of terms.

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.

Public classScoreCachingWrappingScorer
A {@link Scorer} which wraps another scorer and caches the score of the current document. Successive calls to {@link #Score()} will return the same result and will not invoke the wrapped Scorer's score() method, unless the current document has changed.
This class might be useful due to the changes done to the {@link Collector} interface, in which the score is not computed for a document by default, only if the collector requests it. Some collectors may need to use the score in several places, however all they have in hand is a {@link Scorer} object, and might end up computing the score of a document more than once.
Public classScoreDoc
Expert: Returned by low-level search implementations.
Public classScorer
Expert: Common scoring functionality for different types of queries.

A

CopyC#
Scorer
iterates over documents matching a query in increasing order of doc Id.

Document scores are computed using a given

CopyC#
Similarity
implementation.

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.

Public classSearcher
An abstract base class for search implementations. Implements the main search methods.

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

Public classSimilarity
Expert: Scoring API.

Subclasses implement search scoring.

The score of query

CopyC#
q
for document
CopyC#
d
correlates to the cosine-distance or dot-product between document and query vectors in a Vector Space Model (VSM) of Information Retrieval. A document whose vector is closer to the query vector in that model is scored higher. The score is computed as follows:

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.
     

Public classSimilarityDelegator
Expert: Delegating scoring implementation. Useful in {@link Query#GetSimilarity(Searcher)} implementations, to override only certain methods of a Searcher's Similiarty implementation..
Public classSimpleFacetedSearch
Public classSimpleFacetedSearch..::..FacetName
Public classSimpleFacetedSearch..::..Hits
Public classSimpleFacetedSearch..::..HitsPerFacet
Public classSort
Encapsulates sort criteria for returned hits.

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
and
CopyC#
Integer.MAX_VALUE
inclusive. Documents which should appear first in the sort should have low value integers, later documents high values (i.e. the documents should be numbered
CopyC#
1..n
where
CopyC#
1
is the first and
CopyC#
n
the last).

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
and
CopyC#
Long.MAX_VALUE
inclusive. Documents which should appear first in the sort should have low value integers, later documents high values.

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

CopyC#
NaN
and
CopyC#
Infinity
are not supported). Documents which should appear first in the sort should have low values, later documents high values.

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()
for each field name for which a sort is performed. In other words, the size of the cache in bytes is:

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

Public classSortComparator Obsolete.
Abstract base class for sorting hits returned by a Query.

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

Public classSortField
Stores information about how to sort documents by terms in an individual field. Fields must be indexed in order to sort by them.

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

Public classSpanFilter
Abstract base class providing a mechanism to restrict searches to a subset of an index and also maintains and returns position information. This is useful if you want to compare the positions from a SpanQuery with the positions of items in a filter. For instance, if you had a SpanFilter that marked all the occurrences of the word "foo" in documents, and then you entered a new SpanQuery containing bar, you could not only filter by the word foo, but you could then compare position information for post processing.
Public classSpanFilterResult
The results of a SpanQueryFilter. Wraps the BitSet and the position information from the SpanQuery

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

Public classSpanFilterResult..::..PositionInfo
Public classSpanFilterResult..::..StartEnd
Public classSpanQueryFilter
Constrains search results to only match those which also match a provided query. Also provides position information about where each document matches at the cost of extra space compared with the QueryWrapperFilter. There is an added cost to this above what is stored in a {@link QueryWrapperFilter}. Namely, the position information for each matching document is stored.

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

Public classStringIndex
Expert: Stores term text values and document ordering data.
Public classTermQuery
A Query that matches documents containing a term. This may be combined with other terms with a {@link BooleanQuery}.
Public classTermRangeFilter
A Filter that restricts search results to a range of values in a given field.

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.

Public classTermRangeQuery
A Query that matches documents within an exclusive range of terms.

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.

Public classTermRangeTermEnum
Subclass of FilteredTermEnum for enumerating all terms that match the specified range parameters.

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

Public classTermScorer
Expert: A
CopyC#
Scorer
for documents matching a
CopyC#
Term
.
Public classTermsFilter
A filter that contains multiple terms.
Public classTimeLimitedCollector Obsolete.

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.

Public classTimeLimitedCollector..::..TimeExceededException
Thrown when elapsed search time exceeds allowed search time.
Public classTimeLimitingCollector
The {@link TimeLimitingCollector} 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 {@link TimeExceededException}.
Public classTimeLimitingCollector..::..TimeExceededException
Thrown when elapsed search time exceeds allowed search time.
Public classTopDocCollector Obsolete.
A {@link HitCollector} implementation that collects the top-scoring documents, returning them as a {@link TopDocs}. This is used by {@link IndexSearcher} to implement {@link TopDocs}-based search.

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

CopyC#
super()
in order to filter which documents are collected.
Public classTopDocs
Represents hits returned by {@link * Searcher#search(Query,Filter,int)} and {@link * Searcher#search(Query,int)
Public classTopDocsCollector
A base class for all collectors that return a {@link TopDocs} output. This collector allows easy extension by providing a single constructor which accepts a {@link PriorityQueue} as well as protected members for that priority queue and a counter of the number of total hits.
Extending classes can override {@link #TopDocs(int, int)} and {@link #GetTotalHits()} in order to provide their own implementation.
Public classTopFieldCollector
A {@link Collector} that sorts by {@link SortField} using {@link FieldComparator}s.

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.

Public classTopFieldDocCollector Obsolete.
A {@link HitCollector} implementation that collects the top-sorting documents, returning them as a {@link TopFieldDocs}. This is used by {@link IndexSearcher} to implement {@link TopFieldDocs}-based search.

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

CopyC#
super()
in order to filter which documents are collected.
Public classTopFieldDocs
Represents hits returned by {@link Searcher#search(Query,Filter,int,Sort)}.
Public classTopScoreDocCollector
A {@link Collector} implementation that collects the top-scoring hits, returning them as a {@link TopDocs}. This is used by {@link IndexSearcher} to implement {@link TopDocs}-based search. Hits are sorted by score descending and then (when the scores are tied) docID ascending. When you create an instance of this collector you should know in advance whether documents are going to be collected in doc Id order or not.

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

Public classWeight
Expert: Calculate query weights and build query scorers.

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
is used in the following way:
  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)}.
Public classWildcardQuery
Implements the wildcard search query. Supported wildcards are
CopyC#
*
, which matches any character sequence (including the empty one), and
CopyC#
?
, which matches any single character. Note this query can be slow, as it needs to iterate over many terms. In order to prevent extremely slow WildcardQueries, a Wildcard term should not start with one of the wildcards
CopyC#
*
or
CopyC#
?
.

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

Public classWildcardTermEnum
Subclass of FilteredTermEnum for enumerating all terms that match the specified wildcard filter term.

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

Structures

  StructureDescription
Public structureFieldCache_Fields
Public structureScoreDocComparator_Fields Obsolete.
Expert: Compares two ScoreDoc objects for sorting.

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

Interfaces

  InterfaceDescription
Public interfaceByteParser
Interface to parse bytes from document fields.
Public interfaceDoubleParser Obsolete.
Interface to parse doubles from document fields.
Public interfaceFieldCache
Public interfaceFloatParser
Interface to parse floats from document fields.
Public interfaceIntParser
Interface to parse ints from document fields.
Public interfaceLongParser Obsolete.
Interface to parse long from document fields.
Public interfaceParser
Marker interface as super-interface to all parsers. It is used to specify a custom parser to {@link SortField#SortField(String, FieldCache.Parser)}.
Public interfaceScoreDocComparator
Public interfaceSearchable
The interface for search implementations.

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.

Public interfaceShortParser
Interface to parse shorts from document fields.
Public interfaceSortComparatorSource Obsolete.
Expert: returns a comparator for sorting ScoreDocs.

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.