enabled.asciidoc 3.0 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118
  1. [[enabled]]
  2. === `enabled`
  3. Elasticsearch tries to index all of the fields you give it, but sometimes you
  4. want to just store the field without indexing it. For instance, imagine that
  5. you are using Elasticsearch as a web session store. You may want to index the
  6. session ID and last update time, but you don't need to query or run
  7. aggregations on the session data itself.
  8. The `enabled` setting, which can be applied only to the top-level mapping
  9. definition and to <<object,`object`>> fields, causes Elasticsearch to skip
  10. parsing of the contents of the field entirely. The JSON can still be retrieved
  11. from the <<mapping-source-field,`_source`>> field, but it is not searchable or
  12. stored in any other way:
  13. [source,console]
  14. --------------------------------------------------
  15. PUT my_index
  16. {
  17. "mappings": {
  18. "properties": {
  19. "user_id": {
  20. "type": "keyword"
  21. },
  22. "last_updated": {
  23. "type": "date"
  24. },
  25. "session_data": { <1>
  26. "type": "object",
  27. "enabled": false
  28. }
  29. }
  30. }
  31. }
  32. PUT my_index/_doc/session_1
  33. {
  34. "user_id": "kimchy",
  35. "session_data": { <2>
  36. "arbitrary_object": {
  37. "some_array": [ "foo", "bar", { "baz": 2 } ]
  38. }
  39. },
  40. "last_updated": "2015-12-06T18:20:22"
  41. }
  42. PUT my_index/_doc/session_2
  43. {
  44. "user_id": "jpountz",
  45. "session_data": "none", <3>
  46. "last_updated": "2015-12-06T18:22:13"
  47. }
  48. --------------------------------------------------
  49. <1> The `session_data` field is disabled.
  50. <2> Any arbitrary data can be passed to the `session_data` field as it will be entirely ignored.
  51. <3> The `session_data` will also ignore values that are not JSON objects.
  52. The entire mapping may be disabled as well, in which case the document is
  53. stored in the <<mapping-source-field,`_source`>> field, which means it can be
  54. retrieved, but none of its contents are indexed in any way:
  55. [source,console]
  56. --------------------------------------------------
  57. PUT my_index
  58. {
  59. "mappings": {
  60. "enabled": false <1>
  61. }
  62. }
  63. PUT my_index/_doc/session_1
  64. {
  65. "user_id": "kimchy",
  66. "session_data": {
  67. "arbitrary_object": {
  68. "some_array": [ "foo", "bar", { "baz": 2 } ]
  69. }
  70. },
  71. "last_updated": "2015-12-06T18:20:22"
  72. }
  73. GET my_index/_doc/session_1 <2>
  74. GET my_index/_mapping <3>
  75. --------------------------------------------------
  76. <1> The entire mapping is disabled.
  77. <2> The document can be retrieved.
  78. <3> Checking the mapping reveals that no fields have been added.
  79. The `enabled` setting for existing fields and the top-level mapping
  80. definition cannot be updated.
  81. Note that because Elasticsearch completely skips parsing the field
  82. contents, it is possible to add non-object data to a disabled field:
  83. [source,console]
  84. --------------------------------------------------
  85. PUT my_index
  86. {
  87. "mappings": {
  88. "properties": {
  89. "session_data": {
  90. "type": "object",
  91. "enabled": false
  92. }
  93. }
  94. }
  95. }
  96. PUT my_index/_doc/session_1
  97. {
  98. "session_data": "foo bar" <1>
  99. }
  100. --------------------------------------------------
  101. <1> The document is added successfully, even though `session_data` contains non-object data.