+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
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 wrote:
> I think it's a convenient method. Even if not performing, it's still more
> convenient than forcing everyone w
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
bette
Maybe we should deprecate it?
Mike
On Thu, Apr 16, 2009 at 9:04 AM, Mark Miller 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
>>> implementa
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
effic
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 pu
