anchor.diff:  [source,scala]
   ----
   // Spark 1.4 style
  -val df = sql.read()<1>.format("org.elasticsearch.spark.sql"<2>).load("spark/index"<3>)
  +val df = sql.read<1>.format("org.elasticsearch.spark.sql"<2>).load("spark/index"<3>)
   ----
   
   <1> +SQLContext+ _experimental_ +read+ method for arbitrary data sources
   <2> the data source provider - +org.elasticsearch.spark.sql+
   <3> path or resource to load - in this case the index/type in {es}
   
  +In Spark 1.5, this can be further simplified to:
  +
  +[source,scala]
  +----
  +// Spark 1.5 s
  +val df = sql.read.format("es"<1>).load("spark/index")
  +----
  +
  +<1> Use +es+ as an alias instead of the full package name for the +DataSource+ provider
  +
  +
   Whatever API is used, once created, the +DataFrame+ can be accessed freely to manipulate the data.
   
   The __sources__ declaration also allows specific options to be passed in, namely:
  
positive.code: This significantly increases the queries performance and minimizes the CPU, memory and I/O on both Spark and {es} clusters as only the needed data is returned (as oppose to returning the data in bulk only to be processed and discarded by Spark).
  Note the push down operations apply even when one specifies a query - the connector will _enhance_ it according to the specified SQL.
  
  As a side note, {eh} supports _all_ the `Filter`s available in Spark (1.3.0 to 1.4.0) while retaining backwards binary-compatibility with Spark 1.3.0, pushing down to full extent the SQL operations to {es} without any user interference.
  
  To wit, consider the following Spark SQL:
  
  
negative.code: val options = Map("pushdown"<1> -> "true", "es.nodes"<2> -> "someNode", "es.port" -> "9200")
  
  // Spark 1.4 style
  val spark14DF = sql.read.format("org.elasticsearch.spark.sql")
                          .options<3>(options).load("spark/index")
  ----
  
  <1> `pushdown` option - specific to Spark data sources
  