anchor.diff:  CREATE TABLE books (id STRING, cat STRING, title STRING, price FLOAT, in_stock BOOLEAN, author STRING, series STRING, seq INT, genre STRING) ROW FORMAT DELIMITED FIELDS TERMINATED BY ','; --<1>
   
   LOAD DATA LOCAL INPATH '/solr/example/exampledocs/books.csv' OVERWRITE INTO TABLE books; --<2>
  -
  -ADD JAR {packageUser}-hive-serde-{connectorVersion}.jar; --<3>
   
   CREATE EXTERNAL TABLE solr (id STRING, cat_s STRING, title_s STRING, price_f FLOAT, in_stock_b BOOLEAN, author_s STRING, series_s STRING, seq_i INT, genre_s STRING) --<4>
        STORED BY 'com.lucidworks.hadoop.hive.LWStorageHandler' --<5>
  
positive.code: <8> Define the location of Solr (or ZooKeeper if using SolrCloud), the collection in Solr to index the data to, and the query to use when reading the table. This example also refers to a JAAS configuration file that will be used to authenticate to the Kerberized Solr cluster.
  
  // end::example-hive[]
  // end::using-serde[]
  
  // tag::contribute[]
  == How to Contribute
  
negative.code: 
  // end::build-hive[]
  
  // tag::install-hive[]
  == Add the SerDe Jar to Hive Classpath
  
  In order for the Hive SerDe to work with Solr, the SerDe jar must be added to Hive's classpath using the `hive.aux.jars.path` capability. There are several options for this, described below.
  
  It's considered a best practice to use a single directory for all auxiliary jars you may want to add to Hive so you only need to define a single path. However, you must then copy any jars you want to use to that path.
  
  NOTE: The following options all assume you have created such a directory at `/usr/hive/auxlib`; if you use another path, update the path in the examples accordingly.
  
  . If you use Hive with Ambari (as with the Hortonworks HDP distribution), go to menu:Hive[Configs > Advanced], and scroll down to menu:Advanced hive-env[hive-env template]. Find the section where the `HIVE_AUX_JARS_PATH` is defined, and add the path to each line which starts with `export`. What you want will end up looking like:
  +
  [source,plain]
  ----
  # Folder containing extra libraries required for hive compilation/execution can be controlled by:
  if [ "${HIVE_AUX_JARS_PATH}" != "" ]; then
    if [ -f "${HIVE_AUX_JARS_PATH}" ]; then
      export HIVE_AUX_JARS_PATH=${HIVE_AUX_JARS_PATH},/usr/hive/auxlib
    elif [ -d "/usr/hdp/current/hive-webhcat/share/hcatalog" ]; then
      export HIVE_AUX_JARS_PATH=/usr/hdp/current/hive-webhcat/share/hcatalog/hive-hcatalog-core.jar,/usr/hive/auxlib
    fi
  elif [ -d "/usr/hdp/current/hive-webhcat/share/hcatalog" ]; then
    export HIVE_AUX_JARS_PATH=/usr/hdp/current/hive-webhcat/share/hcatalog/hive-hcatalog-core.jar,/usr/hive/auxlib
  fi
  ----
  
  . If not using Ambari or similar cluster management tool, you can add the jar location to `hive/conf/hive-site.xml`:
  +
  [source,xml]
  <property>
    <name>hive.aux.jars.path</name>
    <value>/usr/hive/auxlib</value>
  </property>
  
  . Another option is to launch Hive with the path defined with the `auxpath` variable:
  +
  [source,bash]
  hive --auxpath /usr/hive/auxlib
  
  There are also other approaches that could be used. Keep in mind, though, that the jar *must* be loaded into the classpath, adding it with the `ADD JAR` function is not sufficient.
  // end::install-hive[]
  
  // tag::create-table-intro[]
  == Indexing Data with a Hive External Table
  
  Indexing data to Solr or Fusion requires creating a Hive external table. An external table allows the data in the table to be used (read or write) by another system or application outside of Hive.
  // end::create-table-intro[]
  
  // tag::index-solr[]
  === Indexing Data to Solr
  
  For integration with Solr, the external table allows you to have Solr read from and write to Hive.
  
  To create an external table for Solr, you can use a command similar to below. The properties available are described after the example.
  
  [source,sql]
  hive> CREATE EXTERNAL TABLE solr (id string, field1_s string, field2_i int) <1>
        STORED BY 'com.lucidworks.hadoop.hive.LWStorageHandler' <2>
        LOCATION '/tmp/solr' <3>
        TBLPROPERTIES('solr.server.url' = 'http://localhost:8888/solr', <4>
                      'solr.collection' = 'collection1',
                      'solr.query' = '*:*');
  
  <1> In this example, we have created an external table named "solr", and defined a set of fields and types for the data we will store in the table. See the section <<Defining Fields for Solr>> below for best practices when naming fields.
  
  <2> This defines a custom storage handler (`STORED BY 'com.lucidworks.hadoop.hive.LWStorageHandler'`), which is one of the classes included with the Hive SerDe jar.
  
  <3> The LOCATION indicates the location in HDFS where the table data will be stored. In this example, we have chosen to use `/tmp/solr`.
  
  <4> In the section TBLPROPERTIES, we define several parameters for Solr so the data can be indexed to the right Solr installation and collection. See the section <<Table Properties>> below for details about these parameters.
  
  If the table needs to be dropped at a later time, you can use the DROP TABLE command in Hive. This will remove the metadata stored in the table in Hive, but will not modify the underlying data (in this case, the Solr index).
  
  ==== Defining Fields for Solr
  
  When defining the field names for the Hive table, keep in mind that the field types used to define the table in Hive are *not* sent to Solr when indexing data from a Hive table. The field names are sent, but not the field types. The field types must match or be compatible, however, for queries to complete properly.
  
  The reason why this might be a problem is due to a Solr feature called _schema guessing_. This is Solr's default mode, and when it is enabled Solr looks at incoming data and makes a best guess at the field type.
  
  It can happen that Solr's guess at the correct type may be different from the type defined in Hive, and if this happens you will get a `ClassCastException` in response to queries.
  
  To avoid this problem, you can use a Solr feature called _dynamic fields_. These direct Solr to use specific field types based on a prefix or suffix found on an incoming field name, which overrides Solr guessing at the type. Solr includes by default dynamic field rules for nearly all types it supports, so you only need to use the same suffix on your field names in your Hive tables for the correct type to be defined.
  
  To illustrate this, note the field names in the table example above:
  
  [source,sql]
  CREATE EXTERNAL TABLE solr (id string, field1_s string, field2_i int)
  
  In this example, we have defined the `id` field as a string, `field1_s` as a string, and `field2_i` as an integer. In Solr's default schema, there is a dynamic field rule that any field with a `_s` suffix should be a string. Similarly, there is another rule that any field with `_i` as a suffix should be an integer. This allows us to make sure the field types match.
  
  An alternative to this is to disable Solr's field guessing altogether, but this would require you to create all of your fields in Solr *before* indexing any content from Hive.
  
  For more information about these features and options, please see the following sections of the Apache Solr Reference Guide:
  
  * https://lucene.apache.org/solr/guide/{refGuideVersion}/schemaless-mode.html[Schemaless Mode]
  * https://lucene.apache.org/solr/guide/{refGuideVersion}/dynamic-fields.html[Dynamic Fields]
  * https://lucene.apache.org/solr/guide/{refGuideVersion}/field-types-included-with-solr.html[Field Types Included with Solr]
  
  ==== Table Properties
  The following parameters can be set when defining the table properties:
  
  `solr.zkhost`::
  The location of the ZooKeeper quorum if using LucidWorks in SolrCloud mode. If this property is set along with the `solr.server.url` property, the `solr.server.url` property will take precedence.
  