GET operations should not extract fields from _source.#20158
Merged
jpountz merged 1 commit intoelastic:masterfrom Aug 26, 2016
Merged
GET operations should not extract fields from _source.#20158jpountz merged 1 commit intoelastic:masterfrom
_source.#20158jpountz merged 1 commit intoelastic:masterfrom
Conversation
Contributor
|
LGTM |
Contributor
Author
|
That would be awesome. :) |
This makes GET operations more consistent with `_search` operations which expect `(stored_)fields` to work on stored fields and source filtering to work on the `_source` field. This is now possible thanks to the fact that GET operations do not read from the translog anymore (elastic#20102) and also allows to get rid of `FieldMapper#isGenerated`. The `_termvectors` API (and thus more_like_this too) was relying on the fact that GET operations would extract fields from either stored fields or the source so the logic to do this that used to exist in `ShardGetService` has been moved to `TermVectorsService`. It would be nice that term vectors do not rely on this, but this does not seem to be a low hanging fruit.
7b44cb0 to
3ed0da5
Compare
This was referenced Apr 15, 2022
elasticsearchmachine
pushed a commit
that referenced
this pull request
Apr 20, 2022
668d557 added some `todo` in `ShardGetService` suggest that source might parsed and available in the sourceLookup. https://github.com/elastic/elasticsearch/blob/668d55758b751e848f2b82299e2c5e74af55cd12/src/main/java/org/elasticsearch/index/get/ShardGetService.java#L315 https://github.com/elastic/elasticsearch/blob/668d55758b751e848f2b82299e2c5e74af55cd12/src/main/java/org/elasticsearch/index/get/ShardGetService.java#L431 However ,`SourceLookup` in `ShardGetService` has been remove in #20158 which made these `todo` invalid. One of them has been removed in #83152 This PR remove the left invalid `todo` in `ShardGetService`
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This makes GET operations more consistent with
_searchoperations which expect(stored_)fieldsto work on stored fields and source filtering to work on the_sourcefield. This is now possible thanks to the fact that GET operationsdo not read from the translog anymore (#20102) and also allows to get rid of
FieldMapper#isGenerated.The
_termvectorsAPI (and thus more_like_this too) was relying on the factthat GET operations would extract fields from either stored fields or the source
so the logic to do this that used to exist in
ShardGetServicehas been movedto
TermVectorsService. It would be nice that term vectors do not rely on this,but this does not seem to be a low hanging fruit.
Relates to #15017 which did the same for the
_searchAPI.