-
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 3 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,12 @@ | ||
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); | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -19,4 +19,6 @@ public class KnownIndexVersions { | |
* A sorted list of all known transport versions | ||
*/ | ||
public static final List<IndexVersion> ALL_VERSIONS = List.copyOf(IndexVersions.getAllVersions()); | ||
|
||
public static final List<IndexVersion> ALL_READ_ONLY_VERSIONS = List.copyOf(IndexVersions.getAllReadOnlyVersions()); | ||
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 entirely sure why we need this list copy but since thats the pattern for ALL_VERSIONS I thought its save to do the same. Maybe someone know why we need that for ALL_VERSIONS? 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. By checking its history a bit, I think, the initial intention was to make a defensive copy of the list, which is immutable in the current version. The list was also unmodifiable when it was first introduced: #93384 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 need to have a list with read only versions. Could we instead just add a new method to get read only versions? Also, should we instead have a new method that returns all versions, writeable and read-only, as opposed to having special tests for read-only indices? My expectations it that the majority of the cases will need read support, and no write, hence the special case should probably be for writing and not for reading. 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 what I said above is necessarily correct. Switching randomizations to include read-only version cause quite a bit of issues. It makes sense to add for now a new list, we'll clean it up later. A question remains if that list should contain all versions including readonly or only read-only versions. |
||
} |
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.