Remove ability to set the value of meta fields inside _source
#11074
Conversation
This file contains 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
rjernst
added
v2.0.0-beta1
:Search/Mapping
| if (!rootMapper.includeInObject() && rootMapper instanceof FieldMapper) { | ||
| newFieldMappers.add((FieldMapper<?>) rootMapper); | ||
| if (rootMapper instanceof FieldMapper) { | ||
| newFieldMappers.add((FieldMapper)rootMapper); |
There was a problem hiding this comment.
s/FieldMapper/FieldMapper<?>/ ?
|
This looks great! I think we should also add a note about this to the migration guide and have a simple test that checks that specifying these fields still works on old indices? |
rjernst
force-pushed
the
pr/include-in-object-removal
branch
from
5c9fe7a
to
ffd59e1
Compare
rjernst
added a commit
to rjernst/elasticsearch
that referenced
this pull request
May 11, 2015
A few meta fields can currently be set within a document's source. However, the recommended way to set meta fields like this is through the api, and setting within the document can be a performance trap (e.g. needing to find _id in order to route the document). This change removes the ability to set meta fields within a document source for 2.0+ indexes. closes elastic#11051 closes elastic#11074
|
@jpountz I pushed a commit adding a migration note and tests. I actually found while testing that only |
A few meta fields can currently be set within a document's source. However, the recommended way to set meta fields like this is through the api, and setting within the document can be a performance trap (e.g. needing to find _id in order to route the document). This change removes the ability to set meta fields within a document source for 2.0+ indexes. closes elastic#11051 closes elastic#11074
rjernst
force-pushed
the
pr/include-in-object-removal
branch
from
ffd59e1
to
1df807d
Compare
rjernst
force-pushed
the
pr/include-in-object-removal
branch
from
1df807d
to
f766b26
Compare
|
LGTM |
rjernst
added a commit
that referenced
this pull request
May 13, 2015
Mappings: Remove ability to set meta fields inside documents
clintongormley
changed the title
_source
rjernst
added a commit
to rjernst/elasticsearch
that referenced
this pull request
Oct 7, 2015
We previously removed the ability to specify metadata fields inside documents in elastic#11074, but the backcompat left leniency that allowed this to still occur. This change locks down parsing so any metadata field found while parsing a document results in an exception. This only affects 2.0+ indexes; backcompat is maintained. closes elastic#13740
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
A few meta fields can currently be set within a document's source.
However, the recommended way to set meta fields like this is through
the api, and setting within the document can be a performance trap
(e.g. needing to find _id in order to route the document).
This change removes the ability to set meta fields within
a document source for 2.0+ indexes.
closes #11051