Skip to content

Replace some usages of QueryShardContext#getMapperService #63239

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversation

javanna
Copy link
Member

@javanna javanna commented Oct 5, 2020

QueryShardContext has a getter that allows to have access to MapperService. In many cases, it is misused to lookup field types which QueryShardContext has a specific method for. This commit replaces those usages with a function String -> MappedFieldType.

There are also a few other places where MapperService is retrieved to call methods that are also available directly on QueryShardContext, which are replaced as part of this PR too.

QueryShardContext a getter that allows to have access to the MapperService. In many cases, it is misused to lookup field types which QueryShardContext has a specific method for. This commit replaces those usages with a function String -> MappedFieldType .
@javanna javanna added :Search Foundations/Mapping Index mappings, including merging and defining field types >refactoring v8.0.0 v7.10.0 labels Oct 5, 2020
@javanna javanna requested a review from romseygeek October 5, 2020 12:48
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-search (:Search/Mapping)

@elasticmachine elasticmachine added the Team:Search Meta label for search team label Oct 5, 2020
Copy link
Contributor

@romseygeek romseygeek left a comment

Choose a reason for hiding this comment

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

This is a nice cleanup! And I think we can clean up yet further...

I think we can remove the field type lookup entirely from LuceneChangesSnapshot - it's used after we've loaded stored fields for a post-process step, but that step is done only to format numeric valued fields and the changes snapshot isn't looking at user-defined fields at all.

@@ -144,7 +144,7 @@ protected int doHashCode() {

@Override
protected ScoreFunction doToFunction(QueryShardContext context) {
MappedFieldType fieldType = context.getMapperService().fieldType(field);
MappedFieldType fieldType = context.fieldMapper(field);
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe we should rename this fieldType rather than fieldMapper?

Copy link
Member Author

Choose a reason for hiding this comment

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

yes indeed, I planned to do it as a follow-up

@@ -87,9 +87,9 @@ public Status needsField(FieldInfo fieldInfo) {
: Status.NO;
}

public void postProcess(MapperService mapperService) {
public final void postProcess(Function<String, MappedFieldType> fieldTypeLookup) {
Copy link
Contributor

Choose a reason for hiding this comment

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

I do wonder if we can remove this step entirely, or replace it with the ValueFetcher functionality somehow - for a followup though.

Copy link
Contributor

Choose a reason for hiding this comment

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

So this doesn't do anything to the _id, _source or _routing fields, so I think we can remove the call to it entirely from LuceneChangesSnapshot and possibly a few other places as well.

Copy link
Member Author

Choose a reason for hiding this comment

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

ok I will look at it, possibly make this change in a separate PR then.

Copy link
Contributor

Choose a reason for hiding this comment

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

++

@javanna
Copy link
Member Author

javanna commented Oct 5, 2020

run elasticsearch-ci/packaging-sample-windows

@javanna
Copy link
Member Author

javanna commented Oct 5, 2020

@romseygeek I went ahead and adapted some more places, the PR got quite bigger though, could you have another look please?

Copy link
Contributor

@romseygeek romseygeek left a comment

Choose a reason for hiding this comment

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

LGTM, thanks @javanna

@javanna javanna merged commit cf130f3 into elastic:master Oct 5, 2020
javanna added a commit to javanna/elasticsearch that referenced this pull request Oct 6, 2020
As part of elastic#63239 we have moved some usages of `QueryShardContext#getMapperService` that were looking up a field type through the `fieldType` method, to use the existing `QueryShardContext#fieldMapper`. The latter though has additional handling for unmapped fields when the functionality is enabled, and may throw exception if the field is not mapped. This additional behaviour is not desirable and may cause issues in cases where the callers have their own specific handling for situations where the field is not mapped.

To address this we introduce an additional fieldType method to `QueryShardContext` that allows to simply look up a field type given its name.

relates to elastic#63239
javanna added a commit that referenced this pull request Oct 7, 2020
As part of #63239 we have moved some usages of QueryShardContext#getMapperService that were looking up a field type through the fieldType method, to use the existing QueryShardContext#fieldMapper. The latter though has additional handling for unmapped fields when the functionality is enabled, and may throw exception if the field is not mapped. This additional behaviour is not desirable and may cause issues in cases where the callers have their own specific handling for situations where the field is not mapped.

To address this we introduce an additional isFieldMapped method to QueryShardContext that allows to check if a field is mapped or not.

relates to #63239
@javanna javanna added v7.11.0 and removed v7.10.0 labels Oct 7, 2020
javanna added a commit to javanna/elasticsearch that referenced this pull request Oct 8, 2020
)

QueryShardContext has a getter that allows to have access to MapperService. In many cases, it is misused to lookup field types which QueryShardContext has a specific method for. This commit replaces those usages with a function String -> MappedFieldType.

There are also a few other places where MapperService is retrieved to call methods that are also available directly on QueryShardContext, which are replaced as part of this commit too.
javanna added a commit that referenced this pull request Oct 12, 2020
QueryShardContext has a getter that allows to have access to MapperService. In many cases, it is misused to lookup field types which QueryShardContext has a specific method for. This commit replaces those usages with a function String -> MappedFieldType.

There are also a few other places where MapperService is retrieved to call methods that are also available directly on QueryShardContext, which are replaced as part of this commit too.
javanna added a commit to javanna/elasticsearch that referenced this pull request Oct 12, 2020
As part of elastic#63239 we have moved some usages of QueryShardContext#getMapperService that were looking up a field type through the fieldType method, to use the existing QueryShardContext#fieldMapper. The latter though has additional handling for unmapped fields when the functionality is enabled, and may throw exception if the field is not mapped. This additional behaviour is not desirable and may cause issues in cases where the callers have their own specific handling for situations where the field is not mapped.

To address this we introduce an additional isFieldMapped method to QueryShardContext that allows to check if a field is mapped or not.

relates to elastic#63239
javanna added a commit that referenced this pull request Oct 12, 2020
As part of #63239 we have moved some usages of QueryShardContext#getMapperService that were looking up a field type through the fieldType method, to use the existing QueryShardContext#fieldMapper. The latter though has additional handling for unmapped fields when the functionality is enabled, and may throw exception if the field is not mapped. This additional behaviour is not desirable and may cause issues in cases where the callers have their own specific handling for situations where the field is not mapped.

To address this we introduce an additional isFieldMapped method to QueryShardContext that allows to check if a field is mapped or not.

relates to #63239
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>refactoring :Search Foundations/Mapping Index mappings, including merging and defining field types Team:Search Meta label for search team v7.11.0 v8.0.0-alpha1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants