[ 
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]

Reply via email to