Conversation
romseygeek
added
>breaking
:Search Foundations/Mapping
|
Pinging @elastic/es-search (:Search/Mapping) |
|
@pgomulka @jakelandis I think we'll eventually want to hide the special case logic in |
| private static final DeprecationLogger deprecationLogger = new DeprecationLogger( | ||
| LogManager.getLogger(QueryShardContext.class)); | ||
| public static final String TYPES_DEPRECATION_MESSAGE = "[types removal] Using the _type field " + | ||
| "in queries and aggregations is deprecated, prefer to use a field instead."; |
There was a problem hiding this comment.
nit: If this is only applicable for v7 compatibility mode, should we cal this constant: TYPES_DEPRECATION_MESSAGE_V7?
There was a problem hiding this comment.
Should we remove _type field from SORTED_META_FIELDS constant?
| import org.elasticsearch.search.aggregations.support.ValuesSourceType; | ||
|
|
||
| @Deprecated | ||
| public final class TypeFieldType extends ConstantFieldType { |
There was a problem hiding this comment.
Is this class only be used for V7 compatibility mode? may be also worth to put a comment specifying this.
|
if this PR can wait for #53228 to be merged we can use the infrastructure to wrap v7 code and see that type related yml tests from 7.x are still passing |
|
@pgomulka that's a good idea, we might be able to move things into the compatibility module |
|
This has got very old, I'm going to close and open a new PR. |
|
Related to #62838 |
7 participants
Now that nested documents have their own nested path metadata field in 8x, the
_typefield itself is entirely unnecessary. This commit removes theTypeFieldMapper,and adds some special-case logic to
QueryShardContextto return a singleton instanceof
TypeFieldTypewhen somebody asks for the_typefield to build queries.