+1 on further handling (LUCENE-1592). I just wanted to get a doc change in now rather than wait for that to complete. The statment that some implementations provide more efficient impls is very misleading (its almost an assertion that one exists) when no impls that ship with Lucene in fact do.
On Thu, Apr 16, 2009 at 9:57 AM, Michael McCandless < luc...@mikemccandless.com> wrote: > That would be great... we need someone to pull a patch together (for > SegmentReader & Multi*Reader to implement it efficiently). > > Mike > > On Thu, Apr 16, 2009 at 9:50 AM, Shai Erera <ser...@gmail.com> wrote: > > I think it's a convenient method. Even if not performing, it's still more > > convenient than forcing everyone who wants to use it to implement it by > > himself. Perhaps a better implementation will exist in the future, and > thus > > everyone who'll use this method will be silently upgraded. Maybe such a > > better implementation should be considered? > > > > On Thu, Apr 16, 2009 at 4:46 PM, Michael McCandless > > <luc...@mikemccandless.com> wrote: > >> > >> Maybe we should deprecate it? > >> > >> Mike > >> > >> On Thu, Apr 16, 2009 at 9:04 AM, Mark Miller <markrmil...@gmail.com> > >> wrote: > >> > Mark Miller wrote: > >> >> > >> >> Robert Muir wrote: > >> >>> > >> >>> while I was mucking with term enumeration i found that > >> >>> TermEnum.skipTo() > >> >>> has a very simple implementation and has in javadocs that 'some > >> >>> implementations are considerably more efficent', yet SegmentTermEnum > >> >>> definitely doesn't reimplement it in a more efficient way. > >> >>> > >> >>> For my purposes to skip around i simply close the term enum and get > a > >> >>> new > >> >>> one from the indexReader at a different starting point. > >> >>> > >> >>> Not that I want to touch it, just mentioning i thought it was a > little > >> >>> non-obvious that skipTo() is so inefficient, it keeps enumerating > >> >>> until > >> >>> compareTo() returns what it wants... > >> >>> > >> >>> -- > >> >>> Robert Muir > >> >>> rcm...@gmail.com <mailto:rcm...@gmail.com> > >> >> > >> >> Indeed - somewhat related: > >> >> https://issues.apache.org/jira/browse/LUCENE-1592 > >> >> > >> > I've changed > >> > > >> > "Some implementations are considerably more efficient than that." > >> > > >> > to > >> > > >> > "Some implementations *could* be considerably more efficient than a > >> > linear > >> > scan. > >> > Check the implementation to be sure." > >> > > >> > -- > >> > - Mark > >> > > >> > http://www.lucidimagination.com > >> > > >> > > >> > > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > >> > For additional commands, e-mail: java-dev-h...@lucene.apache.org > >> > > >> > > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > >> For additional commands, e-mail: java-dev-h...@lucene.apache.org > >> > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > >
