This has been elucidating, thanks! On a related topic:
I need the ability to pull results lazily, so that I can decide whether to terminate the search iteration early, and ultimately I need to delegate that decision to callers of *my* API.
My first question is: did I overlook support for this in Lucene's user-facing API? What I see in Lucene (Collector-based) seems to be all push-style; the Searcher retrieves all, or the top N results, stores them and returns them all at once.
Basically what I wanted was a method nextDoc() that I could call repeatedly to retrieve all of the docIDs returned by the search, or at any rate, as many as needed.
Not finding this, I wrote a class that would do. What I ended up doing was subclassing DocIdSetIterator and copying some of the logic I saw in IndexSearcher (IIRC) (create a Weight, iterate over subReaders creating Scorers, retrieve docID from scorers, correcting for docBase offset).
So my second question is, assuming this isn't already provided somewhere, does it belong in IndexSearcher? Is it worth posting a patch? I'm a little concerned that because I ended up having to access some internal members marked as experimental (subReaders, I think?), this might end up not supported or having to track changes in Lucene's internal API.
Last question: what order are documents returned in if you create Scorers with ordered=true - is that always ascending docID order?
-Mike --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
