dot-expand.asciidoc 3.0 KB

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