anchor.diff:  By default, {es} provides {ref}/docs-index_.html[automatic index and mapping] when data is added under an index that has not been created before. In other words, data can be added into {es} without the index and the mappings being defined a priori. This is quite convenient since {es} automatically adapts to the data being fed to it - moreover, if certain entries have extra fields, {es} schema-less nature allows them to be indexed without any issues.
   
   [[auto-mapping-type-loss]]
  -It is important to remember that automatic mapping uses the payload values to identify its {ref}/mapping-core-types.html[type], using the *first document* creates the mapping. {eh} communicates with {es} through JSON which does not provide any type information, rather only the field names and their values. One can think of it as 'type erasure' or information loss; for example JSON does not differentiate integer numeric types - `byte`, `short`, `int`, `long` are all placed in the same `long` 'bucket'. this can have unexpected side-effects since the type information is _guessed_ such as:
  +It is important to remember that automatic mapping uses the payload values to identify its {ref}/mapping-types.html[type], using the *first document* creates the mapping. {eh} communicates with {es} through JSON which does not provide any type information, rather only the field names and their values. One can think of it as 'type erasure' or information loss; for example JSON does not differentiate integer numeric types - `byte`, `short`, `int`, `long` are all placed in the same `long` 'bucket'. this can have unexpected side-effects since the type information is _guessed_ such as:
   
   [float]
   ===== numbers mapped only as `long`/`double`
  -Whenever {es} encounters a number, it will allocate the largest type for it since it does not know the exact number type of the field. Allocating a small type (such as `byte`, `int` or `float`) can lead to problems if a future document is larger, so {es} uses a safe default. 
  +Whenever {es} encounters a number, it will allocate the largest type for it since it does not know the exact number type of the field. Allocating a small type (such as `byte`, `int` or `float`) can lead to problems if a future document is larger, so {es} uses a safe default.
   For example, the document:
   [source, json]
   ----
  
positive.code:           "message" : {
              "type" : "string"
            },
            "postDate" : {                       
              "type" : "date",
              "format" : "dateOptionalTime"      <1> 
            },
            "priority" : {
              "type" : "long"                    <2>
  
negative.code: [float]
  === Converting data to {es}
  
  By design, {eh} provides no data transformation or mapping layer itself simply because there is no need for them: Hadoop is designed to do ETL and some libraries (like Pig and Hive) provide type information themselves; further more {es} has rich support for mapping out of the box including automatic detection,  dynamic/schema-less mapping, templates and full manual control.
  Need to split strings into token, do data validation or eliminate unneeded data ? There are plenty of ways to do that in Hadoop before reading/writing data from/to {es}; need control over how data is stored in {es} ? Use {es} APIs to define the  {ref}/indices-put-mapping.html[mapping], to update {ref}/indices-update-settings.html[settings] or add generic {ref}/mapping-meta-field.html[meta-data].
  
  ////
  Instead of 'reinventing the wheel' and replicating functionality, {eh} focuses on what is missing by recognizing and leveraging existing features.
  ////
  
  [float]
  