Namespace Lucene.Net.Index.Sorter
Provides index sorting capablities. The application can use any Sort specification, e.g. to sort by fields using DocValues or FieldCache, or to reverse the order of the documents (by using SortField.Type.DOC in reverse). Multi-level sorts can be specified the same way you would when searching, by building Sort from multiple SortFields.
SortingMergePolicy can be used to make Lucene sort segments before merging them. This will ensure that every segment resulting from a merge will be sorted according to the provided <xref:Lucene.Net.Search.Sort>. This however makes merging and thus indexing slower.
Sorted segments allow for early query termination when the sort order matches index order. This makes query execution faster since not all documents need to be visited. Please note that this is an expert feature and should not be used without a deep understanding of Lucene merging and document collection.
Classes
BlockJoinComparerSource
Helper class to sort readers that contain blocks of documents.
Note that this class is intended to used with SortingMergePolicy, and for other purposes has some limitations:
- Cannot yet be used with SearchAfter(ScoreDoc, Query, Filter, Int32, Sort)
- Filling sort field values is not yet supported.
EarlyTerminatingSortingCollector
A Lucene.Net.Search.ICollector that early terminates collection of documents on a per-segment basis, if the segment was sorted according to the given Lucene.Net.Search.Sort.
NOTE: the Lucene.Net.Search.ICollector detects sorted segments according to SortingMergePolicy, so it's best used in conjunction with it. Also, it collects up to a specified m_numDocsToCollect from each segment, and therefore is mostly suitable for use in conjunction with collectors such as TopDocsCollector<T>, and not e.g. TotalHitCountCollector.
NOTE: If you wrap a TopDocsCollector<T> that sorts in the same order as the index order, the returned GetTopDocs() will be correct. However the total of TotalHits hit count will be underestimated since not all matching documents will have been collected.
NOTE: This Lucene.Net.Search.ICollector uses ToString() to detect whether a segment was sorted with the same Lucene.Net.Search.Sort. This has two implications:
- if a custom comparer is not implemented correctly and returns different identifiers for equivalent instances, this collector will not detect sorted segments,
- if you suddenly change the Lucene.Net.Index.IndexWriter's SortingMergePolicy to sort according to another criterion and if both the old and the new Lucene.Net.Search.Sorts have the same identifier, this Lucene.Net.Search.ICollector will incorrectly detect sorted segments.
SortingAtomicReader
An Lucene.Net.Index.AtomicReader which supports sorting documents by a given Lucene.Net.Search.Sort. You can use this class to sort an index as follows:
IndexWriter writer; // writer to which the sorted index will be added
DirectoryReader reader; // reader on the input index
Sort sort; // determines how the documents are sorted
AtomicReader sortingReader = SortingAtomicReader.Wrap(SlowCompositeReaderWrapper.Wrap(reader), sort);
writer.AddIndexes(reader);
reader.Dispose(); // alternatively, you can use a using block
writer.Dispose(); // alternatively, you can use a using blockSortingMergePolicy
A Lucene.Net.Index.MergePolicy that reorders documents according to a Lucene.Net.Search.Sort before merging them. As a consequence, all segments resulting from a merge will be sorted while segments resulting from a flush will be in the order in which documents have been added.
NOTE: Never use this policy if you rely on AddDocuments(IEnumerable<IEnumerable<IIndexableField>>, Analyzer) to have sequentially-assigned doc IDs, this policy will scatter doc IDs.
NOTE: This policy should only be used with idempotent Lucene.Net.Search.Sorts so that the order of segments is predictable. For example, using INDEXORDER in reverse (which is not idempotent) will make the order of documents in a segment depend on the number of times the segment has been merged.