> > Yes, if skipTo would work more performant, I could easily use it in > > TrieRange and would be happy as noted before. Currently, a new TermEnum > is > > created on each sub-range. When TrieRange was committed and therefore > > updated, for me it was (and still is) not clear, why skipTo may not be > as > > fast as a new TermEnum. > Check Michael's link below, this method (and its ugly implementation) > is a random offspring of some ancient bugfix. Nobody loved it, and it > grew in neglect. > > >> But other people (like me) might use mmapped indexes, so cost(new > >> TermEnum)/cost(index read) relation looks different for us. > >> > >> > See also this, for historical context: > >> > > >> > http://markmail.org/message/2e7kpvyi3bqtgjwt#query:lucene%20termenum%20sk > >> ipto+page:1+mid:lb46mbbgpgbnnuxk+state:results > >> Darn! And api-wise it looks like a legitimate method :)
I think, we should do what was suggested in this thread: Remove it or deprecate it, if it is nowhere used internally to prevent people (like me in the past) to try to use it. Maybe put an additional warning in the JavaDocs in addition to deprecation: "This method is not effective. It is recommeneded to create a new TermEnum with IndexReader.terms(Term) instead of skipping." Or we fix it. Uwe --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
