lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Smiley (JIRA)" <>
Subject [jira] [Commented] (LUCENE-6121) Fix CachingTokenFilter to propagate reset() the first time
Date Fri, 19 Dec 2014 15:59:13 GMT


David Smiley commented on LUCENE-6121:

Sure; that point occurred to me too.

If there is no term attribute (as strange as that may be), then this reset() call needs to
be guarded by {{if (numTokens > 0)}} or else a double-reset will ensue.  See it?

Also, I'd like to remove the needless = null|false initializations to variables where it's
not needed due to the compiler figuring out it's not needed (which IntelliJ helpfully points

> Fix CachingTokenFilter to propagate reset() the first time
> ----------------------------------------------------------
>                 Key: LUCENE-6121
>                 URL:
>             Project: Lucene - Core
>          Issue Type: Improvement
>            Reporter: David Smiley
>            Assignee: David Smiley
>             Fix For: 5.0, Trunk
>         Attachments: LUCENE-6121_CachingTokenFilter_reset_propagates_reset_if_not_cached.patch,
> CachingTokenFilter should have been propagating reset() _but only the first time_ and
thus you would then use CachingTokenFilter in a more normal way – wrap it and call reset()
then increment in a loop, etc., instead of knowing you need to reset() on what it wraps but
not this token filter itself. That's weird. It's ab-normal for a TokenFilter to never propagate
reset, so every user of CachingTokenFilter to date has worked around this by calling reset()
on the underlying input instead of the final wrapping token filter (CachingTokenFilter in
this case).

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message