Deprecate support for chained multi-fields. #42330
Conversation
We now issue a deprecation warning if a multi-field definition contains a `[fields]` entry. This PR also simplifies the definition of `MultiFieldParserContext`. Addresses elastic#41267.
jtibshirani
added
:Search Foundations/Mapping
|
Pinging @elastic/es-search |
jtibshirani
force-pushed
the
chained-multifields
branch
from
33b4003 to
aa9cb58
Compare
jtibshirani
force-pushed
the
chained-multifields
branch
from
aa9cb58 to
22d00ed
Compare
There was a problem hiding this comment.
Thank you very much for implementing a deprecation check along with the warnings!
I left a couple comments asking for tweaks, but overall that part looks good. I don't see any obvious problems with the changes to the mapping code/tests, but I'm not very familiar with it.
| if (issues.size() > 0) { | ||
| return new DeprecationIssue(DeprecationIssue.Level.CRITICAL, | ||
| "Multi-fields within multi-fields", | ||
| "https://www.elastic.co/guide/en/elasticsearch/reference/7.2/breaking-changes-7.2.html" + |
There was a problem hiding this comment.
Historically, we've usually linked to the next major version breaking changes list (8.0 in this case), but this also has a few issues: Until the 8.0 branch is cut, the only way to link to these docs is by using master as the version in the URL, which 404s when 8.0 is actually released.
While having this in the breaking changes list for 7.2 and linking to it there would resolve this problem, I don't think it's how we've typically organized the breaking changes list, and might cause issues keeping up to date if we change the deprecation plan.
Basically there's a bunch of problems with how the breaking changes lists and links to them have work at the moment and there's no good options, all I'm pointing out here is that this is different from what we usually do.
There was a problem hiding this comment.
Would you suggest I change this to master for now, for consistency with other deprecation issues we'll be adding? Then I guess we will update all of these links at once when the 8.0 branch is cut?
There was a problem hiding this comment.
Yes, I think that's what I would recommend for now, that way if we make a change to the docs to make the situation better it'll be easier to do all at once.
| fieldLevelMappingIssue(indexMetaData, ((mappingMetaData, sourceAsMap) -> issues.addAll( | ||
| findInPropertiesRecursively(mappingMetaData.type(), sourceAsMap, IndexDeprecationChecks::containsChainedMultiFields)))); | ||
| if (issues.size() > 0) { | ||
| return new DeprecationIssue(DeprecationIssue.Level.CRITICAL, |
There was a problem hiding this comment.
Will 8.0 fail to open an index which has chained multi-fields that was created in 7.x? Usually we support all indices created in ($MAJOR-1), even if they use deprecated features.
If 8.0 will be able to open indices created in 7.x that have chained multi-fields, this should be Level.WARNING rather than Level.CRITICAL.
There was a problem hiding this comment.
Thanks for pointing this out, I will make sure to update the 8.0 PR to still allow chained multi-fields on indices created prior to 8.0. With that change, I'll also be able to lower this to Level.WARNING.
| @@ -110,6 +112,43 @@ public void testTooManyFieldsCheck() throws IOException { | |||
| assertEquals(0, withDefaultFieldIssues.size()); | |||
| } | |||
|
|
|||
| public void testChainedMultiFields() throws IOException { | |||
| XContentBuilder xContent = XContentFactory.jsonBuilder().startObject() | |||
There was a problem hiding this comment.
I'd like this test case to include at least one field that has a non-chained multi-field to verify that the warning message only contains the fields with a problem.
|
@gwbrown this is now ready for another look. |
This PR contains a straight backport of #41926, and also updates the
migration documentation and deprecation info API for 7.x.
The code currently contains references to 7.2, but I will update these to 7.3
once we cut the branch over.