On Tuesday, March 19, 2002, at 10:32 PM, Otis Gospodnetic wrote:
> Hello,
>
> --- David Smiley <david.smiley@verizon.net> wrote:
>> I have reported bugs about Lucene in the fall of 2001 but no Lucene
>> developer has responded. I am sending this summary as a reminder.
>>
>> My original message to the mailing list is here:
>>
>> [Lucene-dev] More bugs
>> http://www.geocrawler.com/archives/3/2626/2001/8/0/6409669/
>>
>> The bugs at SourceForge are here:
>>
>> DateFilter: call enum.next() first
>
> DateFilter.java has changed since the report, but I think I found the
> piece of code that you were referring to.
> After looking at DateFilter, TermEnum, and FilteredTermEnum it seems to
> me that next() does not need to be called first. This is not
> java.util.Enumeration enum, it is TermEnum's enum.
>
> Also, if you look at methods next() and term() in FilteredTermEnum
> you'll see that term() does need to be called first, otherwise the
> first term would get skipped.
Hmmm, ok. So this next()-method design pattern that Lucene is using
here is not the same as how Enumeration/Iterator/ResultSet works...
ok; water under the bridge. I used the "find usages" feature of my
IDE ("IDEA" by IntelliJ/Netbrains) on the TermEnum.next() method just
now to see how other callers work with this method. Your findings
are correct. I did find one caller that appears to not call it
correctly however: TermInfosReader.readIndex() line 111. If it is
calling it correctly in this case for some obscure exceptional reason
then there is documentation missing to explain why.
Anyway, the reason I first thought that this was a bug was because
term() returned null and DateFilter.bits() was expecting it not to.
It thus seems that that a bug does remain, and it is that
DateFilter.bits() does not handle cases in which there are no terms
to iterate over.
~ David Smiley
--
To unsubscribe, e-mail: <mailto:lucene-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-user-help@jakarta.apache.org>
|