dot-expand.asciidoc 2.9 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119
  1. [[dot-expand-processor]]
  2. === Dot Expander Processor
  3. Expands a field with dots into an object field. This processor allows fields
  4. with dots in the name to be accessible by other processors in the pipeline.
  5. Otherwise these <<accessing-data-in-pipelines,fields>> can't be accessed by any processor.
  6. [[dot-expender-options]]
  7. .Dot Expand Options
  8. [options="header"]
  9. |======
  10. | Name | Required | Default | Description
  11. | `field` | yes | - | The field to expand into an object field
  12. | `path` | no | - | The field that contains the field to expand. Only required if the field to expand is part another object field, because the `field` option can only understand leaf fields.
  13. include::common-options.asciidoc[]
  14. |======
  15. [source,js]
  16. --------------------------------------------------
  17. {
  18. "dot_expander": {
  19. "field": "foo.bar"
  20. }
  21. }
  22. --------------------------------------------------
  23. // NOTCONSOLE
  24. For example the dot expand processor would turn this document:
  25. [source,js]
  26. --------------------------------------------------
  27. {
  28. "foo.bar" : "value"
  29. }
  30. --------------------------------------------------
  31. // NOTCONSOLE
  32. into:
  33. [source,js]
  34. --------------------------------------------------
  35. {
  36. "foo" : {
  37. "bar" : "value"
  38. }
  39. }
  40. --------------------------------------------------
  41. // NOTCONSOLE
  42. If there is already a `bar` field nested under `foo` then
  43. this processor merges the `foo.bar` field into it. If the field is
  44. a scalar value then it will turn that field into an array field.
  45. For example, the following document:
  46. [source,js]
  47. --------------------------------------------------
  48. {
  49. "foo.bar" : "value2",
  50. "foo" : {
  51. "bar" : "value1"
  52. }
  53. }
  54. --------------------------------------------------
  55. // NOTCONSOLE
  56. is transformed by the `dot_expander` processor into:
  57. [source,js]
  58. --------------------------------------------------
  59. {
  60. "foo" : {
  61. "bar" : ["value1", "value2"]
  62. }
  63. }
  64. --------------------------------------------------
  65. // NOTCONSOLE
  66. If any field outside of the leaf field conflicts with a pre-existing field of the same name,
  67. then that field needs to be renamed first.
  68. Consider the following document:
  69. [source,js]
  70. --------------------------------------------------
  71. {
  72. "foo": "value1",
  73. "foo.bar": "value2"
  74. }
  75. --------------------------------------------------
  76. // NOTCONSOLE
  77. Then the `foo` needs to be renamed first before the `dot_expander`
  78. processor is applied. So in order for the `foo.bar` field to properly
  79. be expanded into the `bar` field under the `foo` field the following
  80. pipeline should be used:
  81. [source,js]
  82. --------------------------------------------------
  83. {
  84. "processors" : [
  85. {
  86. "rename" : {
  87. "field" : "foo",
  88. "target_field" : "foo.bar""
  89. }
  90. },
  91. {
  92. "dot_expander": {
  93. "field": "foo.bar"
  94. }
  95. }
  96. ]
  97. }
  98. --------------------------------------------------
  99. // NOTCONSOLE
  100. The reason for this is that Ingest doesn't know how to automatically cast
  101. a scalar field to an object field.