Dot expander

The dot_expander processor is a tool that helps you work with hierarchical data. It transforms fields containing dots into object fields, making them accessible to other processors in the pipeline. Without this transformation, fields with dots cannot be processed.

The following is the syntax for the dot_expander processor:

  1. {
  2.   "dot_expander": {
  3.     "field": "field.to.expand" 
  4.   }
  5. }

copy

Configuration parameters

The following table lists the required and optional parameters for the dot_expander processor.

ParameterRequired/OptionalDescription
fieldRequiredThe field to be expanded into an object field.
pathOptionalThis field is only required if the field to be expanded is nested within another object field. This is because the field parameter only recognizes leaf fields.
descriptionOptionalA brief description of the processor.
ifOptionalA condition for running the processor.
ignore_failureOptionalIf set to true, failures are ignored. Default is false.
on_failureOptionalA list of processors to run if the processor fails.
tagOptionalAn identifier tag for the processor. Useful for debugging in order to distinguish between processors of the same type.

Using the processor

Follow these steps to use the processor in a pipeline.

Step 1: Create a pipeline

The following query creates a dot_expander processor that will expand two fields named user.address.city and user.address.state into nested objects:

  1. PUT /_ingest/pipeline/dot-expander-pipeline
  2. {
  3.   "description": "Dot expander processor",
  4.   "processors": [
  5.     {
  6.       "dot_expander": {
  7.         "field": "user.address.city"
  8.       }
  9.     },
  10.     {
  11.       "dot_expander":{
  12.        "field": "user.address.state"
  13.       }
  14.     }
  15.   ]
  16. }

copy

Step 2 (Optional): Test the pipeline

It is recommended that you test your pipeline before you ingest documents.

To test the pipeline, run the following query:

  1. POST _ingest/pipeline/dot-expander-pipeline/_simulate
  2. {
  3.   "docs": [
  4.     {
  5.       "_index": "testindex1",
  6.       "_id": "1",
  7.       "_source": {
  8.         "user.address.city": "New York",
  9.         "user.address.state": "NY"
  10.       }
  11.     }
  12.   ]
  13. }

copy

Response

The following example response confirms that the pipeline is working as expected:

  1. {
  2.   "docs": [
  3.     {
  4.       "doc": {
  5.         "_index": "testindex1",
  6.         "_id": "1",
  7.         "_source": {
  8.           "user": {
  9.             "address": {
  10.               "city": "New York",
  11.               "state": "NY"
  12.             }
  13.           }
  14.         },
  15.         "_ingest": {
  16.           "timestamp": "2024-01-17T01:32:56.501346717Z"
  17.         }
  18.       }
  19.     }
  20.   ]
  21. }

Step 3: Ingest a document

The following query ingests a document into an index named testindex1:

  1. PUT testindex1/_doc/1?pipeline=dot-expander-pipeline
  2. {
  3.   "user.address.city": "Denver",
  4.   "user.address.state": "CO"
  5. }

copy

Step 4 (Optional): Retrieve the document

To retrieve the document, run the following query:

  1. GET testindex1/_doc/1

copy

Response

The following response confirms that the specified fields were expanded into nested fields:

  1. {
  2.   "_index": "testindex1",
  3.   "_id": "1",
  4.   "_version": 1,
  5.   "_seq_no": 3,
  6.   "_primary_term": 1,
  7.   "found": true,
  8.   "_source": {
  9.     "user": {
  10.       "address": {
  11.         "city": "Denver",
  12.         "state": "CO"
  13.       }
  14.     }
  15.   }
  16. }

The path parameter

You can use the path parameter to specify the path to a dotted field within an object. For example, the following pipeline specifies the address.city field that is located within the user object:

  1. PUT /_ingest/pipeline/dot-expander-pipeline
  2. {
  3.   "description": "Dot expander processor",
  4.   "processors": [
  5.     {
  6.       "dot_expander": {
  7.         "field": "address.city",
  8.         "path": "user"
  9.       }
  10.     },
  11.     {
  12.       "dot_expander":{
  13.        "field": "address.state",
  14.        "path": "user"
  15.       }
  16.     }
  17.   ]
  18. }

copy

You can simulate the pipeline as follows:

  1. POST _ingest/pipeline/dot-expander-pipeline/_simulate
  2. {
  3.   "docs": [
  4.     {
  5.       "_index": "testindex1",
  6.       "_id": "1",
  7.       "_source": {
  8.         "user": {
  9.           "address.city": "New York",
  10.           "address.state": "NY"
  11.         }
  12.       }
  13.     }
  14.   ]
  15. }

copy

The dot_expander processor transforms the document into the following structure:

  1. {
  2.   "user": {
  3.     "address": {
  4.       "city": "New York",
  5.       "state": "NY"
  6.     }
  7.   }
  8. }

Field name conflicts

If a field already exists with the same path as the path to which the dot_expander processor should expand the value, the processor merges the two values into an array.

Consider the following pipeline that expands the field user.name:

  1. PUT /_ingest/pipeline/dot-expander-pipeline
  2. {
  3.   "description": "Dot expander processor",
  4.   "processors": [
  5.     {
  6.       "dot_expander": {
  7.         "field": "user.name"
  8.       }
  9.     }
  10.   ]
  11. }

copy

You can simulate the pipeline with a document containing two values with the exact same path user.name:

  1. POST _ingest/pipeline/dot-expander-pipeline/_simulate
  2. {
  3.   "docs": [
  4.     {
  5.       "_index": "testindex1",
  6.       "_id": "1",
  7.       "_source": {
  8.         "user.name": "John", 
  9.         "user": {
  10.           "name": "Steve"
  11.         }
  12.       }
  13.     }
  14.   ]
  15. }

copy

The response confirms that the values were merged into an array:

  1. {
  2.   "docs": [
  3.     {
  4.       "doc": {
  5.         "_index": "testindex1",
  6.         "_id": "1",
  7.         "_source": {
  8.           "user": {
  9.             "name": [
  10.               "Steve",
  11.               "John"
  12.             ]
  13.           }
  14.         },
  15.         "_ingest": {
  16.           "timestamp": "2024-01-17T01:44:57.420220551Z"
  17.         }
  18.       }
  19.     }
  20.   ]
  21. }

If a field contains the same name but a different path, then the field needs to be renamed. For example, the following _simulate call returns a parse exception:

  1. POST _ingest/pipeline/dot-expander-pipeline/_simulate
  2. {
  3.   "docs": [
  4.     {
  5.       "_index": "testindex1",
  6.       "_id": "1",
  7.       "_source": {
  8.         "user": "John",
  9.         "user.name": "Steve"
  10.       }
  11.     }
  12.   ]
  13. }

To avoid the parse exception, first rename the field by using the rename processor:

  1. PUT /_ingest/pipeline/dot-expander-pipeline
  2. {
  3.   "processors" : [
  4.     {
  5.       "rename" : {
  6.         "field" : "user",
  7.         "target_field" : "user.name"
  8.       }
  9.     },
  10.     {
  11.       "dot_expander": {
  12.         "field": "user.name"
  13.       }
  14.     }
  15.   ]
  16. }

copy

Now you can simulate the pipeline:

  1. POST _ingest/pipeline/dot-expander-pipeline/_simulate
  2. {
  3.   "docs": [
  4.     {
  5.       "_index": "testindex1",
  6.       "_id": "1",
  7.       "_source": {
  8.         "user": "John",
  9.         "user.name": "Steve"
  10.       }
  11.     }
  12.   ]
  13. }

copy

The response confirms that the fields were merged:

  1. {
  2.   "docs": [
  3.     {
  4.       "doc": {
  5.         "_index": "testindex1",
  6.         "_id": "1",
  7.         "_source": {
  8.           "user": {
  9.             "name": [
  10.               "John",
  11.               "Steve"
  12.             ]
  13.           }
  14.         },
  15.         "_ingest": {
  16.           "timestamp": "2024-01-17T01:52:12.864432419Z"
  17.         }
  18.       }
  19.     }
  20.   ]
  21. }