put-mapping.asciidoc 4.6 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195
  1. [[indices-put-mapping]]
  2. == Put Mapping
  3. The PUT mapping API allows you to add a new type to an existing index, or new
  4. fields to an existing type:
  5. [source,js]
  6. --------------------------------------------------
  7. PUT twitter <1>
  8. {
  9. "mappings": {
  10. "tweet": {
  11. "properties": {
  12. "message": {
  13. "type": "string"
  14. }
  15. }
  16. }
  17. }
  18. }
  19. PUT twitter/_mapping/user <2>
  20. {
  21. "properties": {
  22. "name": {
  23. "type": "string"
  24. }
  25. }
  26. }
  27. PUT twitter/_mapping/tweet <3>
  28. {
  29. "properties": {
  30. "user_name": {
  31. "type": "string"
  32. }
  33. }
  34. }
  35. --------------------------------------------------
  36. // AUTOSENSE
  37. <1> <<indices-create-index,Creates an index>> called `twitter` with the `message` field in the `tweet` <<mapping-type,mapping type>>.
  38. <2> Uses the PUT mapping API to add a new mapping type called `user`.
  39. <3> Uses the PUT mapping API to add a new field called `user_name` to the `tweet` mapping type.
  40. More information on how to define type mappings can be found in the
  41. <<mapping,mapping>> section.
  42. [float]
  43. === Multi-index
  44. The PUT mapping API can be applied to multiple indices with a single request.
  45. It has the following format:
  46. [source,js]
  47. --------------------------------------------------
  48. PUT /{index}/_mapping/{type}
  49. { body }
  50. --------------------------------------------------
  51. * `{index}` accepts <<multi-index,multiple index names>> and wildcards.
  52. * `{type}` is the name of the type to update.
  53. * `{body}` contains the mapping changes that should be applied.
  54. [[updating-field-mappings]]
  55. [float]
  56. === Updating field mappings
  57. In general, the mapping for existing fields cannot be updated. There are some
  58. exceptions to this rule. For instance:
  59. * new <<properties>> can be added to <<object>> fields.
  60. * new <<multi-fields,multi-fields>> can be added to existing fields.
  61. * <<doc-values>> can be disabled, but not enabled.
  62. * the <<ignore-above>> parameter can be updated.
  63. For example:
  64. [source,js]
  65. -----------------------------------
  66. PUT my_index <1>
  67. {
  68. "mappings": {
  69. "user": {
  70. "properties": {
  71. "name": {
  72. "properties": {
  73. "first": {
  74. "type": "string"
  75. }
  76. }
  77. },
  78. "user_id": {
  79. "type": "string",
  80. "index": "not_analyzed"
  81. }
  82. }
  83. }
  84. }
  85. }
  86. PUT my_index/mapping/user
  87. {
  88. "properties": {
  89. "name": {
  90. "properties": {
  91. "last": { <2>
  92. "type": "string"
  93. }
  94. }
  95. },
  96. "user_id": {
  97. "type": "string",
  98. "index": "not_analyzed",
  99. "ignore_above": 100 <3>
  100. }
  101. }
  102. }
  103. -----------------------------------
  104. // AUTOSENSE
  105. <1> Create an index with a `first` field under the `name` <<object>> field, and a `user_id` field.
  106. <2> Add a `last` field under the `name` object field.
  107. <3> Update the `ignore_above` setting from its default of 0.
  108. Each <<mapping-params,mapping parameter>> specifies whether or not its setting
  109. can be updated on an existing field.
  110. [float]
  111. [[merging-conflicts]]
  112. === Conflicts between fields in different types
  113. Fields in the same index with the same name in two different types must have
  114. the same mapping, as they are backed by the same field internally. Trying to
  115. <<updating-field-mappings,update a mapping parameter>> for a field which
  116. exists in more than one type will throw an exception, unless you specify the
  117. `update_all_types` parameter, in which case it will update that parameter
  118. across all fields with the same name in the same index.
  119. TIP: The only parameters which are exempt from this rule -- they can be set to
  120. different values on each field -- can be found in <<field-conflicts>>.
  121. For example:
  122. [source,js]
  123. -----------------------------------
  124. PUT my_index
  125. {
  126. "mappings": {
  127. "type_one": {
  128. "properties": {
  129. "text": { <1>
  130. "type": "string",
  131. "analyzer": "standard"
  132. }
  133. }
  134. },
  135. "type_two": {
  136. "properties": {
  137. "text": { <1>
  138. "type": "string",
  139. "analyzer": "standard"
  140. }
  141. }
  142. }
  143. }
  144. }
  145. PUT my_index/_mapping/type_one <2>
  146. {
  147. "properties": {
  148. "text": {
  149. "type": "string",
  150. "analyzer": "standard",
  151. "search_analyzer": "whitespace"
  152. }
  153. }
  154. }
  155. PUT my_index/_mapping/type_one?update_all_types <3>
  156. {
  157. "properties": {
  158. "text": {
  159. "type": "string",
  160. "analyzer": "standard",
  161. "search_analyzer": "whitespace"
  162. }
  163. }
  164. }
  165. -----------------------------------
  166. // AUTOSENSE
  167. <1> Create an index with two types, both of which contain a `text` field which have the same mapping.
  168. <2> Tring to update the `search_analyzer` just for `type_one` throws an exception like `"Merge failed with failures..."`.
  169. <3> Adding the `update_all_types` parameter updates the `text` field in `type_one` and `type_two`.