A mapping API defines how Elasticsearch fields are stored and analyzed before indexing. Explicit mappings prevent dynamic mapping from inferring an unsuitable schema and let structured fields support sorting, filtering, and aggregations. section 4.0 section 4.3
Use the two explicit-mapping approaches for different schema changes:
- Create the index and its initial mapping together by sending a mappings object to the create index API. section 4.3 section 4.3.1
- Add new fields to an existing or empty index through its _mapping endpoint. section 4.3 section 4.3.2
- Keep the properties object at the root of an _mapping request; initial index creation wraps it inside mappings. section 4.3.2
- Treat existing field types as fixed: adding fields is supported, but changing an existing type is not. section 4.3.2
Define and extend an employee index
Create the initial schema with an HTTP PUT request: PUT employees { "mappings": { "properties": { "name": { "type": "text" }, "age": { "type": "integer" }, "email": { "type": "keyword" }, "address": { "properties": { "street": { "type": "text" }, "country": { "type": "text" } } } } } } Later, add fields to the live index: PUT employees/_mapping { "properties": { "joining_date": { "type": "date", "format": "dd-MM-yyyy" }, "phone_number": { "type": "keyword" } } } The date mapping supports date operations, while keyword preserves the phone number without tokenization. Elasticsearch infers the inner address object from its nested properties. section 4.3.1 section 4.3.2
Compare index creation with later schema updates through the mapping and indexing API flow. section 4.3
