-
Notifications
You must be signed in to change notification settings - Fork 24.9k
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
Add unmatch_mapping_type
, and support array of types
#103171
Add unmatch_mapping_type
, and support array of types
#103171
Conversation
Add an unmatch_mapping_type condition to dynamic templates, and add support for specifying a list of types to match_mapping_type.
@felixbarny @javanna I took a stab at addressing the linked issues. Could you please tell me if this looks directionally sensible, and if you can spot any major issues? If it looks alright I'll proceed to add docs and probably expand the tests a bit. The main thing I'm unsure about is backwards compatibility with respect to the serialisation changes. Do we need to do something special for cluster upgrades? |
A good template for this change would be this PR:
Seems like that PR doesn't do anything special here with regards to the serialization changes. However, I think there may be a problematic situation that can occur in this code line in a mixed version cluster scenario (such as when doing a rolling upgrade): elasticsearch/server/src/main/java/org/elasticsearch/index/mapper/DynamicTemplate.java Line 314 in b9c2980
If one node in a cluster gets updated and the user sends a mapping update request to that node, it may propagate that mapping to older nodes that expect the content of But maybe all of that is a non issue, depending on how the update process works. IIRC, at first, all non-master nodes are updated before the master node. Also, updating the mapping would go though the master node that triggers a cluster state update to propagate the mappings to other nodes. During that process, the master node would validate the mappings. I think that makes sure that ES will only accept mappings with an array in |
server/src/main/java/org/elasticsearch/index/mapper/DynamicTemplate.java
Outdated
Show resolved
Hide resolved
server/src/main/java/org/elasticsearch/index/mapper/DynamicTemplate.java
Outdated
Show resolved
Hide resolved
server/src/main/java/org/elasticsearch/index/mapper/DynamicTemplate.java
Outdated
Show resolved
Hide resolved
server/src/main/java/org/elasticsearch/index/mapper/DynamicTemplate.java
Outdated
Show resolved
Hide resolved
…plate.java Co-authored-by: Felix Barnsteiner <[email protected]>
- Use addEntriesToPatternList like match/path_match etc. - Serialise (un)match_mapping_type as specified, except for single-value lists which are always serialised as a non-list value. Implicit "match_mapping_type: *" is still not serialised, but an explicit setting will now be serialised where it was not before.
... to highlight the original purpose, which is to unmatch an internal object field whose path may match a leaf field.
@elasticmachine run elasticsearch-ci/packaging-tests-windows-sample |
Hi @axw, I've created a changelog YAML for you. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a minor suggestion, otherwise LGTM. This also needs to be reviewed by the search team before merging.
server/src/main/java/org/elasticsearch/index/mapper/DynamicTemplate.java
Outdated
Show resolved
Hide resolved
Move runtime-supported type filtering.
Pinging @elastic/es-search (Team:Search) |
@salvatore-campagna would you be able to review this PR? Or otherwise tag someone else more appropriate? 🙏 |
Pinging @elastic/es-storage-engine (Team:StorageEngine) |
@@ -257,7 +260,8 @@ static DynamicTemplate parse(String name, Map<String, Object> conf) throws Mappe | |||
List<String> pathUnmatch = new ArrayList<>(4); | |||
Map<String, Object> mapping = null; | |||
boolean runtime = false; | |||
String matchMappingType = null; | |||
List<String> matchMappingType = new ArrayList<>(4); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is the size of the array 4? Just to have a size that is lower than he default?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This uses the same initial size of the array list as the other lists a few lines above. I think this is because we expect most of these to have one or a few values, so a custom default value 4 aims for more efficiency than the generic default value.
builder.field("unmatch_mapping_type", unmatchMappingType.get(0)); | ||
} else { | ||
builder.field("unmatch_mapping_type", unmatchMappingType); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Logic seems similar...maybe extract a method just passing a list and a string?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let me add that
LGTM, I left a question and a comment. |
… size of the list
Add an
unmatch_mapping_type
condition to dynamic templates (supporting one or more types), and add support for specifying a list of types tomatch_mapping_type
.Closes #102795
Closes #102807