Mailing List Archive

Hello,

> SegmentTermEnum.clone(), term == null
>
http://sourceforge.net/tracker/index.php?func=detail&aid=451315&group_id=3922&
> atid=103922

Aha, this was a bug, indeed, but it looks like this bug has been fixed
about 6 months ago:

revision 1.2
date: 2001/10/11 15:14:14; author: scottganyo; state: Exp; lines: +1
-1
Fix NullPointerException in clone() method when the Term is null.

Otis


__________________________________________________
Do You Yahoo!?
Yahoo! Sports - live college hoops coverage
http://sports.yahoo.com/

--
To unsubscribe, e-mail: <mailto:lucene-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-user-help@jakarta.apache.org>

Hello,
Has anyone else observed this behaviour?

> Wrong ordering from Document.fields()
>
http://sourceforge.net/tracker/index.php?func=detail&aid=451317&group_id=3922&
> atid=103922

It looks like java.util.Enumeration is used to store the fields, so if
Enumeration guarantees order than this should, too.
Could you please provide a self-contained test case that I can just put
somewhere, compile, and run?
I can't compile the snippet in the above bug report.

> No software is bug free; I just want to help make Lucene better. If
> I can be of any help, please ask.

Thanks!
Otis


__________________________________________________
Do You Yahoo!?
Yahoo! Sports - live college hoops coverage
http://sports.yahoo.com/

--
To unsubscribe, e-mail: <mailto:lucene-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-user-help@jakarta.apache.org>

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>

I have attached my bug report test code. I took what I reported last
year to SourceForge, made some tweaks, made it a JUnit test-case, and
added documentation, and finally verified the error is still present
(it is).