[
https://issues.apache.org/jira/browse/SOLR-6022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13982029#comment-13982029
]
Erick Erickson commented on SOLR-6022:
--------------------------------------
Ryan:
Cool, way to jump on it! And when I did my quick scan for calls to getAnalyzer,
I didn't think about the local variables, subclasses that overrode the method
call etc., good catch.
Can we really just change the public method without providing a back-compat?
Something like
public Analyzer getIndexAnalyzer() {
return indexAnalyzer;
}
/**
* @deprecated As of release 5.0, replaced by {@link #getIndexAnalyzer()}
*/
@Deprecated // Remove in 5.0
public Analyzer getAnalyzer() { return getIndexAnalyzer(); }
And a CHANGES.txt entry too.
Or is it OK in a case like this to just rename the method and provide a
CHANGES.txt entry? What do others think?
> Rename getAnalyzer to getIndexAnalyzer
> --------------------------------------
>
> Key: SOLR-6022
> URL: https://issues.apache.org/jira/browse/SOLR-6022
> Project: Solr
> Issue Type: Improvement
> Reporter: Ryan Ernst
> Attachments: SOLR-6022.patch
>
>
> We have separate index/query analyzer chains, but the access methods for the
> analyzers do not match up with the names. This can lead to unknowingly using
> the wrong analyzer chain (as it did in SOLR-6017). We should do this
> renaming in trunk, and deprecate the old getAnalyzer function in 4x.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
