Dynamic vs explicit mapping in Elasticsearch - Visual Side-by-Side Comparison

Concept Flow - Dynamic vs explicit mapping

Start: Indexing document

↓

Check mapping type

↓

Dynamic mapping

↓

Infer field types

↓

Add fields to mapping

↓

Store document in index

↓

End

When a document is indexed, Elasticsearch either infers field types dynamically or uses explicit predefined mappings before storing the document.

Execution Sample

Elasticsearch

{
  "mappings": {
    "properties": {
      "name": {"type": "text"},
      "age": {"type": "integer"}
    }
  }
}

// Index document with fields name and age

This example shows explicit mapping where field types are defined before indexing documents.

Execution Table

Step	Action	Mapping Type	Field Processed	Mapping Update	Result
1	Index document {"name": "Alice", "age": 30}	Explicit	name	Exists as text	Field accepted as text
2	Index document {"name": "Alice", "age": 30}	Explicit	age	Exists as integer	Field accepted as integer
3	Index document {"city": "Paris"}	Explicit	city	Not in mapping	Rejected or error (depends on settings)
4	Index document {"name": "Bob", "age": 25, "city": "Paris"}	Dynamic	name	Exists as text	Field accepted as text
5	Index document {"name": "Bob", "age": 25, "city": "Paris"}	Dynamic	age	Exists as integer	Field accepted as integer
6	Index document {"name": "Bob", "age": 25, "city": "Paris"}	Dynamic	city	Inferred as text	Field added dynamically
7	Index document {"name": "Charlie", "age": "thirty"}	Dynamic	age	Inferred as integer before	Type conflict error or dynamic mapping update
8	Stop	-	-	-	No more documents to index

💡 Execution stops when no more documents are indexed or mapping conflicts occur.

Variable Tracker

Variable	Start	After 1	After 2	After 3	After 4	After 5	After 6	Final
Mapping fields	{}	{"name": "text"}	{"name": "text", "age": "integer"}	{"name": "text", "age": "integer"}	{"name": "text", "age": "integer", "city": "text"}	{"name": "text", "age": "integer", "city": "text"}	{"name": "text", "age": "integer", "city": "text"}	{"name": "text", "age": "integer", "city": "text"}
Document indexed	None	{"name": "Alice", "age": 30}	{"name": "Alice", "age": 30}	{"city": "Paris"} (rejected in explicit)	{"name": "Bob", "age": 25, "city": "Paris"}	{"name": "Bob", "age": 25, "city": "Paris"}	{"name": "Charlie", "age": "thirty"} (conflict)	Stopped

Key Moments - 3 Insights

Why does indexing a new field fail in explicit mapping?

In explicit mapping, only predefined fields are accepted. As shown in step 3 of the execution_table, the 'city' field is not defined, so Elasticsearch rejects it.

How does dynamic mapping add new fields?

Dynamic mapping infers the field type from the document and adds it automatically to the mapping, as seen in steps 4-6 where 'city' is added dynamically.

What happens if a field's type conflicts with previous mapping?

If a new document has a field with a different type than previously mapped, Elasticsearch raises a type conflict error, as in step 7 with 'age' field.

Visual Quiz - 3 Questions

Look at the execution_table, at which step is a new field added dynamically?

A Step 4

B Step 3

C Step 2

D Step 1

💡 Hint

Check the 'Mapping Update' column for when 'city' is added dynamically.

According to variable_tracker, what fields exist after step 2 in explicit mapping?

A Only 'name'

B 'name', 'age', and 'city'

C 'name' and 'age'

D No fields

💡 Hint

Look at the 'Mapping fields' row after 'After 2' column.

If explicit mapping allowed unknown fields, how would step 3 change?

A Field 'city' would be rejected

B Field 'city' would be accepted without error

C Field 'city' would be added dynamically

D Mapping would be deleted

💡 Hint

Refer to the difference between explicit and dynamic mapping in the execution_table steps 3 and 4.

Concept Snapshot

Dynamic vs explicit mapping in Elasticsearch:
- Explicit mapping: define fields and types before indexing
- Dynamic mapping: Elasticsearch infers and adds fields automatically
- Explicit rejects unknown fields unless updated
- Dynamic can cause type conflicts if data changes
- Choose explicit for control, dynamic for flexibility

Full Transcript

When you add data to Elasticsearch, it needs to know what type each field is, like text or number. You can tell it exactly by making an explicit mapping before adding data. Then, only those fields are allowed. If you try to add a new field not in the mapping, it will reject it. Or, you can let Elasticsearch guess the types by using dynamic mapping. It looks at your data and adds new fields automatically. But if later you add a field with a different type, it causes an error. This example showed how explicit mapping accepts only known fields and dynamic mapping adds new fields on the fly. Understanding this helps you decide how to organize your data in Elasticsearch.

Practice

1. What is the main difference between dynamic mapping and explicit mapping in Elasticsearch?

easy

A. Dynamic mapping automatically detects field types, explicit mapping requires manual definition.

B. Dynamic mapping requires manual field type definition, explicit mapping guesses types automatically.

C. Dynamic mapping disables indexing, explicit mapping enables indexing.

D. Dynamic mapping is only for text fields, explicit mapping is only for numeric fields.

Solution

1. Step 1: Understand dynamic mapping

   Dynamic mapping lets Elasticsearch guess the data type of fields automatically when new data arrives.

2. Step 2: Understand explicit mapping

   Explicit mapping means you define each field's type and settings manually before indexing data.

3. Final Answer:

   Dynamic mapping automatically detects field types, explicit mapping requires manual definition. -> Option A

4. Quick Check:

   Dynamic = auto detect, Explicit = manual define [OK]

Hint: Dynamic guesses types; explicit means you set types yourself [OK]

Common Mistakes:

• Confusing which mapping guesses types
• Thinking dynamic disables indexing
• Assuming explicit mapping is only for numbers

2. Which JSON snippet correctly defines an explicit mapping for a field age as an integer?

easy

A. {"mappings": {"properties": {"age": "number"}}}

B. {"mappings": {"age": {"type": "text"}}}

C. {"properties": {"age": "integer"}}

D. {"mappings": {"properties": {"age": {"type": "integer"}}}}

Solution

1. Step 1: Check correct mapping structure

   Explicit mapping requires "mappings" with "properties" and field name with type inside.

2. Step 2: Verify field type for age

   "age" field must have "type": "integer" to define it as integer.

3. Final Answer:

   {"mappings": {"properties": {"age": {"type": "integer"}}}} -> Option D

4. Quick Check:

   Correct JSON structure with integer type [OK]

Hint: Explicit mapping needs mappings > properties > field > type [OK]

Common Mistakes:

• Missing 'properties' level in JSON
• Using wrong type names like 'number' instead of 'integer'
• Placing fields outside 'mappings'

3. Given this explicit mapping, what will be the type of the price field after indexing?

{"mappings": {"properties": {"price": {"type": "float"}}}}

medium

A. integer

B. text

C. float

D. keyword

Solution

1. Step 1: Read the explicit mapping for price

   The mapping defines "price" with "type": "float", so Elasticsearch will store it as a floating-point number.

2. Step 2: Understand type assignment

   Explicit mapping overrides dynamic guessing, so price will be float regardless of input data.

3. Final Answer:

   float -> Option C

4. Quick Check:

   Explicit float mapping means price = float [OK]

Hint: Explicit mapping sets exact type, here float for price [OK]

Common Mistakes:

• Assuming price becomes integer automatically
• Thinking dynamic mapping applies here
• Confusing float with text or keyword

4. You have this mapping snippet:

{"mappings": {"properties": {"date": {"type": "date"}}}}

After indexing a document with "date": "not-a-date", what error will occur?

medium

A. No error, field stored as text

B. Document rejected with parsing exception

C. Field ignored silently

D. Mapping conflict error due to wrong type

Solution

1. Step 1: Check mapping type for date

   The field "date" is explicitly mapped as "date" type, so Elasticsearch expects a valid date format.

2. Step 2: Indexing invalid date string

   Indexing "not-a-date" will cause a parsing exception because it cannot convert the string to a date.

3. Final Answer:

   Document rejected with parsing exception -> Option B

4. Quick Check:

   Invalid date string causes parsing error [OK]

Hint: Invalid date string causes parsing error, not silent ignore [OK]

Common Mistakes:

• Thinking field stores as text automatically
• Assuming no error occurs
• Believing field is ignored silently

5. You want to prevent Elasticsearch from automatically adding new fields to your index but still allow existing fields to be indexed. Which mapping setting should you use?

hard

A. "dynamic": "strict"

B. "dynamic": "true"

C. "dynamic": "false"

D. "dynamic": "runtime"

Solution

1. Step 1: Understand dynamic mapping options

   "dynamic": "true" allows new fields to be added automatically, "false" ignores new fields, "strict" rejects documents with unknown fields.

2. Step 2: Choose setting to prevent new fields but allow existing

   "strict" rejects documents with new fields, so only existing fields are indexed, preventing unwanted additions.

3. Final Answer:

   "dynamic": "strict" -> Option A

4. Quick Check:

   Use strict to block new fields, allow existing [OK]

Hint: Use dynamic: strict to block new fields but keep existing [OK]

Common Mistakes:

• Using dynamic: false which ignores new fields silently
• Using dynamic: true which allows new fields
• Confusing runtime with dynamic setting