Skip to content

Conversation

@cbuescher
Copy link
Member

@cbuescher cbuescher commented Mar 28, 2019

This PR reduces some method scopes and makes a few methods static where they don't use instance fields.
Also slightly changing AnalysisRegistry#produceAnalyze return a NamedAnalyzer instead of having
a side effect on the analyzer map passed in. In addition, removing the unused environment
field from CustomAnalyzerProvider.

@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-search

Reducing some methods scope and marking them as static where possible. Removing
"alias" support from AnalysisRegistry#produceAnalyze and changing that method to
return a NamedAnalyzer instead of having a side effect on the analyzer map
passed in.
Also, CustomAnalyzerProvider doesn't seem to need the environment field.
@cbuescher cbuescher force-pushed the small-Refactoring-AnalysisRegistry branch from 5c306c4 to 86adf42 Compare March 29, 2019 22:29
charFilterFactoryFactories, tokenizerFactoryFactories), (k, v) -> {
throw new IllegalStateException("already registered analyzer with name: " + entry.getKey());
});
final String analyzerAliasKey = "index.analysis.analyzer." + entry.getKey() + ".alias";
Copy link
Contributor

@mayya-sharipova mayya-sharipova Mar 31, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The original code had this comment: // TODO: remove alias support completely when we no longer support pre 5.0 indices
Should we remove this part as we don't support pre 5.0 indexes any more?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, I was wondering the same. I understood the comment to mean we want to remove the alias support (which I think we have already) but not the error that prevents these settings to be silently ignored going forward. But I will take another look and maybe consult with sb. else before proceeding to merge this.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 to remove, this is not supported nor documented since version 5.

Copy link
Contributor

@mayya-sharipova mayya-sharipova left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cbuescher Thanks, very nice refactoring indeed. Side effects are difficult to track, and returning a value instead is much better. I wonder if we should do the same about processNormalizerFactory.

@cbuescher
Copy link
Member Author

I wonder if we should do the same about processNormalizerFactory.

Good point, I now saw they look quite similar, I didn't touch that method in my own refactorings so I missed it. I'd like to do that in a follow up though if possible.

@cbuescher cbuescher merged commit c95a95b into elastic:master Apr 8, 2019
cbuescher pushed a commit that referenced this pull request Apr 8, 2019
Reducing some methods scope and marking them as static where possible. Removing
"alias" support from AnalysisRegistry#produceAnalyze and changing that method to
return a NamedAnalyzer instead of having a side effect on the analyzer map passed in.
Also, CustomAnalyzerProvider doesn't seem to need the `environment` field.
gurkankaymak pushed a commit to gurkankaymak/elasticsearch that referenced this pull request May 27, 2019
Reducing some methods scope and marking them as static where possible. Removing
"alias" support from AnalysisRegistry#produceAnalyze and changing that method to
return a NamedAnalyzer instead of having a side effect on the analyzer map passed in.
Also, CustomAnalyzerProvider doesn't seem to need the `environment` field.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants