Open
Description
Summary
ECS follows the design philosophy of establishing conventions on field names used in different places across the schema. When certain field names come with an obvious data type, ECS could more explicitly establish the convention on which data type to use as well. For example .ip
fields should use type ip
.
Motivation:
Establishing this convention would be useful from multiple points of view:
- clarify guidance for contributors when adding fields to ECS that happen to have such a name-type convention
- clarify guidance for users adding custom fields outside of ECS that happen to have such a name-type convention.
- Users can do whatever they want in their custom fields (including not follow this guidance). But whenever they do, this will spread the feel and predictability of ECS to their custom fields.
- this could be added to the dynamic templates in the ECS sample ES template. This way user's custom unmapped fields could offer better guesses, when they happen to follow one of the name-type conventions.
- Supplementing Elasticsearch' type guesses with good conventions captured in a dynamic template will reduce the need for users to maintain their own templates 🎉
Detailed Design:
Two ideas for such name-type conventions are being discussed in elastic/elasticsearch#64978:
.ip
=> typeip
message
or.message
=> type `text
Others conventions that come to mind:
.version
=> typeversion
- It's not a straightforward migration from pre-existing
keyword
fields called.version
, since the types are not compatible (as of 7.10, at least). But this works for net new fields.
- It's not a straightforward migration from pre-existing
.bytes
,.packets
,.count
,.size
=> typelong
.location
=> typegeo_point