[
https://issues.apache.org/jira/browse/LUCENE-6121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14253665#comment-14253665
]
David Smiley commented on LUCENE-6121:
--------------------------------------
I appreciate it may have seemed "cowboy" from where you sit but I ran tests on
trunk & 5x, precommit as well. Of course this doesn't guarantee no problems.
1. I should switch my 5x environment shell to switch my java environment to
Java 7, not my default (Java 8). Thanks for the quick fix Mike.
2. The test failure seen on trunk was because the test I added fundamentally
requires MockTokenizer to do its thing, and when assertions aren't enabled
(randomly chosen) then it won't. So I committed this moments ago:
{code}
assumeTrue("We want MockAnalyzer to detect double-reset", TEST_ASSERTS_ENABLED);
{code}
I anticipate both trunk/5x should be stable now.
bq. I am sure there are other issues with the method besides the
no-term-att-case, because its complicated. But that means its even more
important to be cautious, e.g. approach this in a separate issue and so on.
I added a test to TestQueryBuilder that tests the behavior we want when there
is no term attribute, since clearly QueryBuilder was written to support that
yet it wasn't tested.
bq. Please, I do not want these changes under this issue.
I don't agree on insisting on a heavy-weight process for minor code clarity
improvements. It's not worth it to create an issue over such things; so it
sits there the way it is. As it is, we need to commit to multiple branches,
which is a PITA. But fine, you have a right to your opinion.
> 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: [email protected]
For additional commands, e-mail: [email protected]
