anchor.diff:  [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.html[meta-data].
  +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. 
  +////
  +Instead of 'reinventing the wheel' and replicating functionality, {eh} focuses on what is missing by recognizing and leveraging existing features.
   ////
   
   [float]
  
positive.code:           "message" : {
              "type" : "string"
            },
            "postDate" : {                       
              "type" : "date",
              "format" : "dateOptionalTime"      <1> 
            },
            "priority" : {
              "type" : "long"                    <2>
  
negative.code: {"error":"MapperParsingException[failed to parse [array]]; nested: NumberFormatException[For input string: \"string\"]; ","status":400}
  ----
  
  because the field +array+ is initially detected as a number (because of +123+) which causes +"string"+ to trigger the parsing exception since clearly it is not a number. The same issue tends to occur with strings might be
  interpreted as dates.
  
  Hence if the defaults need to be overridden and/or if you experience the problems exposed above, potentially due to a diverse dataset, consider using <<explicit-mapping>>.
  