[ 
https://issues.apache.org/jira/browse/LUCENE-6121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14251653#comment-14251653
 ] 

David Smiley commented on LUCENE-6121:
--------------------------------------

The main challenge with doing exactly what the subject calls for, propagating 
reset(), is backwards compatibility. Any user of this would have to know, 
starting with Lucene 5, that they should call reset() on this filter not what 
it contains.  That's easy to overlook and will compile and could lead to some 
head-scratching periods when an exception first triggers.  

[~rcmuir] thought maybe a new class is a solution.  I think that'd be a shame 
when the name of this one is perfectly good, and already known to people.  I 
propose instead that the existing constructor be made private, that a new 
protected one appear (for subclassing) with a boolean resetInput, and a public 
static wrap(input) method appear to be used instead of the old constructor.  
Someone upgrading to Lucene 5 will see a compile error forcing them to look at 
the new API, and we'll spell out that they should now call reset() on this 
filter, not the input.

> 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
>
>
> 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: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to