-
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
Re-add support for some metadata field parameters #118825
Changes from all commits
de38c9e
e898670
e8541bc
2f81e13
3048972
ab3a39b
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,11 +1,11 @@ | ||
pr: 116944 | ||
pr: 118825 | ||
summary: "Remove support for type, fields, `copy_to` and boost in metadata field definition" | ||
area: Mapping | ||
type: breaking | ||
issues: [] | ||
breaking: | ||
title: "Remove support for type, fields, copy_to and boost in metadata field definition" | ||
area: Mapping | ||
details: The type, fields, copy_to and boost parameters are no longer supported in metadata field definition | ||
details: The type, fields, copy_to and boost parameters are no longer supported in metadata field definition starting with version 9. | ||
impact: Users providing type, fields, copy_to or boost as part of metadata field definition should remove them from their mappings. | ||
notable: false |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -10,13 +10,17 @@ | |
package org.elasticsearch.index.mapper; | ||
|
||
import org.elasticsearch.common.Explicit; | ||
import org.elasticsearch.common.logging.DeprecationCategory; | ||
import org.elasticsearch.common.util.Maps; | ||
import org.elasticsearch.common.xcontent.support.XContentMapValues; | ||
import org.elasticsearch.index.IndexVersion; | ||
import org.elasticsearch.index.IndexVersions; | ||
import org.elasticsearch.xcontent.XContentBuilder; | ||
|
||
import java.io.IOException; | ||
import java.util.Iterator; | ||
import java.util.Map; | ||
import java.util.Set; | ||
import java.util.function.Function; | ||
|
||
/** | ||
|
@@ -132,6 +136,8 @@ public final MetadataFieldMapper build(MapperBuilderContext context) { | |
return build(); | ||
} | ||
|
||
private static final Set<String> UNSUPPORTED_PARAMETERS_8_6_0 = Set.of("type", "fields", "copy_to", "boost"); | ||
|
||
public final void parseMetadataField(String name, MappingParserContext parserContext, Map<String, Object> fieldNode) { | ||
final Parameter<?>[] params = getParameters(); | ||
Map<String, Parameter<?>> paramsMap = Maps.newHashMapWithExpectedSize(params.length); | ||
|
@@ -144,6 +150,22 @@ public final void parseMetadataField(String name, MappingParserContext parserCon | |
final Object propNode = entry.getValue(); | ||
Parameter<?> parameter = paramsMap.get(propName); | ||
if (parameter == null) { | ||
IndexVersion indexVersionCreated = parserContext.indexVersionCreated(); | ||
if (indexVersionCreated.before(IndexVersions.UPGRADE_TO_LUCENE_10_0_0) | ||
&& UNSUPPORTED_PARAMETERS_8_6_0.contains(propName)) { | ||
if (indexVersionCreated.onOrAfter(IndexVersions.V_8_6_0)) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I wonder if we should leave the deprecation under that conditional. What do you think? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure I understand entirely. Under which conditions do you think we should issue a deprecation? As I see this atm before 8.6 we silently ignore, from 8.6 to 9 (or rather IndexVersions.UPGRADE_TO_LUCENE_10_0_0) we issue a deprecation and afterwards we throw. Do you mean reorganizing code to reflect that better or different behaviour? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think I misread, we are good then. |
||
// silently ignore type, and a few other parameters: sadly we've been doing this for a long time | ||
deprecationLogger.warn( | ||
DeprecationCategory.API, | ||
propName, | ||
"Parameter [{}] has no effect on metadata field [{}] and will be removed in future", | ||
propName, | ||
name | ||
); | ||
} | ||
iterator.remove(); | ||
continue; | ||
} | ||
throw new MapperParsingException("unknown parameter [" + propName + "] on metadata field [" + name + "]"); | ||
} | ||
parameter.parse(name, parserContext, propNode); | ||
|
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.
I'm not entirely sure if UPGRADE_TO_LUCENE_10_0_0 should be the point in time we should start to throw errors. We first removed support for these parameters with #116944 (8a7491c) at which point we already have more recent IndexVersions (see
elasticsearch/server/src/main/java/org/elasticsearch/index/IndexVersions.java
Line 135 in 8a7491c
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.
good point. Tricky question. I don't expect it to matter a lot because these unsupported params should not be common at all. The removal affects only serverless users indeed, but I'm afraid it can't be associated to a specific index version. If we meant to do so we'd have needed to add an index versions associated with the removal?
I am fine with using what you are using, or in alternative adding a new index version now.