[jira] [Resolved] (LUCENE-6121) Fix CachingTokenFilter to propagate reset() the first time

["David Smiley (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/LUCENE-6121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Smiley resolved LUCENE-6121.
----------------------------------
    Resolution: Fixed

Thanks for your input Rob.

FYI I moved the QueryBuilder buffer.reset() to the end of the previous try-catch that wraps with RuntimeException, so it'll not be swallowed.

> Fix CachingTokenFilter to propagate reset() the first time
> ----------------------------------------------------------
>
>                 Key: LUCENE-6121
>                 URL: https://issues.apache.org/jira/browse/LUCENE-6121
>             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, 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
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org