| 
 | ||||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
| SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD | |||||||||
java.lang.Objectorg.apache.lucene.search.Collector
public abstract class Collector
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 IndexReaders. 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 TopDocsCollector, instead of
 implementing Collector directly:
 
TopDocsCollector is an abstract base class
   that assumes you will retrieve the top N docs,
   according to some criteria, after collection is
   done.  TopScoreDocCollector is a concrete subclass
   TopDocsCollector and sorts according to score +
   docID.  This is used internally by the IndexSearcher search methods that do not take an
   explicit Sort. It is likely the most frequently
   used collector.TopFieldCollector subclasses TopDocsCollector and sorts according to a specified
   Sort object (sort by field).  This is used
   internally by the IndexSearcher search methods
   that take an explicit Sort.
   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).PositiveScoresOnlyCollector wraps any other
   Collector and prevents collection of hits whose score
   is <= 0.0Collector 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 setScorer(org.apache.lucene.search.Scorer) method, to hold onto the
 passed Scorer instance, and call 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
 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 PositiveScoresOnlyCollector.
NOTE: This API is experimental and might change in incompatible ways in the next release.
| Constructor Summary | |
|---|---|
| Collector() | |
| Method Summary | |
|---|---|
| abstract  boolean | acceptsDocsOutOfOrder()Return trueif this collector does not
 require the matching docIDs to be delivered in int sort
 order (smallest to largest) tocollect(int). | 
| abstract  void | collect(int doc)Called once for every document matching a query, with the unbased document number. | 
| abstract  void | setNextReader(IndexReader reader,
              int docBase)Called before collecting from each IndexReader. | 
| abstract  void | setScorer(Scorer scorer)Called before successive calls to collect(int). | 
| Methods inherited from class java.lang.Object | 
|---|
| clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait | 
| Constructor Detail | 
|---|
public Collector()
| Method Detail | 
|---|
public abstract void setScorer(Scorer scorer)
                        throws IOException
collect(int). Implementations
 that need the score of the current document (passed-in to
 collect(int)), should save the passed-in Scorer and call
 scorer.score() when needed.
IOException
public abstract void collect(int doc)
                      throws IOException
 Note: This is called in an inner search loop. For good search performance,
 implementations of this method should not call Searcher.doc(int) or
 IndexReader.document(int) on every hit.
 Doing so can slow searches by an order of magnitude or more.
IOException
public abstract void setNextReader(IndexReader reader,
                                   int docBase)
                            throws IOException
collect(int) will correspond to reader.
 
 Add docBase to the current IndexReaders internal document id to re-base ids
 in collect(int).
reader - next IndexReaderdocBase - 
IOExceptionpublic abstract boolean acceptsDocsOutOfOrder()
true if this collector does not
 require the matching docIDs to be delivered in int sort
 order (smallest to largest) to collect(int).
  Most Lucene Query implementations will visit
 matching docIDs in order.  However, some queries
 (currently limited to certain cases of BooleanQuery) can achieve faster searching if the
 Collector allows them to deliver the
 docIDs out of order.
 Many collectors don't mind getting docIDs out of
 order, so it's important to return true
 here.
| 
 | ||||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
| SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD | |||||||||