[
https://issues.apache.org/jira/browse/LUCENE-5170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13739475#comment-13739475
]
Uwe Schindler edited comment on LUCENE-5170 at 8/14/13 10:09 AM:
-----------------------------------------------------------------
Attached is my patch which fixes the stateful strategy, which is a serious bug:
- The strategy is now looking like {{RewriteMethod}} of MTQ
- The strategy is no longer {{Closeable}} (because its stateless)
- The {{ThreadLocal}} is now part of Analyzer itsself (private), the reuse
strategy has access to it through the {{protected final}} getters and setters
(taking the {{Analyzer}} instance like in {{RewriteMethod}})
- The {{ThreadLocal}} is closed by the analyzer like before, just directly not
through the strategy
- The 2 default strategies are available as static final constants (singletons
in trunk): GLOBAL_REUSE_STRATEGY and PER_FIELD_REUSE_STRATEGY
To preserve backwards:
- The public constructors of the implementation classes were kept alive, so
code using the ReuseStrategy in the old-fashined stateful way can be kept
unchanged. It only reports a deprecation warning to use the constants instead.
- We only have a backwards break for users that implement their own strategy,
which is unlikely, because what else can you do in a strategy? I have no idea,
maybe reuse components by checksum of field name? A fieldname prefix (this
looks like the only sensible use-case)? Maybe have a lifetime (reuse only for a
limited time because synonyms update)?
All tests pass.
was (Author: thetaphi):
Attached is my patch which fixed the stateful strategy, which is a serious
bug:
- The strategy is now looking like {{RewriteMethod}} of MTQ
- The strategy is no longer {{Closeable}} (because its stateless)
- The {{ThreadLocal}} is now part of Analyzer itsself (private), the reuse
strategy has access to is through the {{protected final}} getters and setters
(taking the {{Analyzer}} instance)
- The {{ThreadLocal}} is closed by the analyzer like before, just directly not
through the strategy
- The 2 default strategies are available as static final constants (singletons
in trunk): GLOBAL_REUSE_STRATEGY and PER_FIELD_REUSE_STRATEGY
To preserve backwards:
- The public constructors of the implementation classes were kept alive, so
code using the ReuseStrategy in the old-fashined stateful way can be kept
unchanged. It only reports a deprecation warning to use the constants instead.
- We only have a backwards break for users that implement their own strategy,
which is unlikely, because what else can you do in a strategy? I have no idea,
maybe reuse components by checksum of field name? A fieldname prefix (this
looks like the only sensible use-case)? Maybe have a lifetime (reuse only for a
limited time because synonyms update)?
All tests pass.
> Add getter for reuse strategy to Analyzer, make AnalyzerWrapper's reuse
> strategy configureable
> ----------------------------------------------------------------------------------------------
>
> Key: LUCENE-5170
> URL: https://issues.apache.org/jira/browse/LUCENE-5170
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/other, modules/analysis
> Affects Versions: 4.4
> Reporter: Uwe Schindler
> Assignee: Uwe Schindler
> Fix For: 5.0, 4.5
>
> Attachments: LUCENE-5170.patch, LUCENE-5170.patch
>
>
> If you write an Analyzer that wraps another one (but without using
> AnalyzerWrapper) you may need use the same reuse strategy in your wrapper.
> This is not possible as there is no way to get the reuse startegy (private
> field and no getter).
> An example is ES's NamedAnalyzer, see my comment:
> [https://github.com/elasticsearch/elasticsearch/commit/b9a2fbd8741aa1b9beffb7d2922fc9b4525397e4#src/main/java/org/elasticsearch/index/analysis/NamedAnalyzer.java]
> This would add a getter, just a 3-liner.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]