You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@lucene.apache.org by ct...@apache.org on 2017/05/12 14:35:21 UTC
[11/37] lucene-solr:branch_6_6: squash merge jira/solr-10290 into
master
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/c8c2aab8/solr/solr-ref-guide/src/running-solr.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/running-solr.adoc b/solr/solr-ref-guide/src/running-solr.adoc
new file mode 100644
index 0000000..6cb904d
--- /dev/null
+++ b/solr/solr-ref-guide/src/running-solr.adoc
@@ -0,0 +1,273 @@
+= Running Solr
+:page-shortname: running-solr
+:page-permalink: running-solr.html
+
+This section describes how to run Solr with an example schema, how to add documents, and how to run queries.
+
+[[RunningSolr-StarttheServer]]
+== Start the Server
+
+If you didn't start Solr after installing it, you can start it by running `bin/solr` from the Solr directory.
+
+[source,bash]
+----
+bin/solr start
+----
+
+If you are running Windows, you can start Solr by running `bin\solr.cmd` instead.
+
+[source,plain]
+----
+bin\solr.cmd start
+----
+
+This will start Solr in the background, listening on port 8983.
+
+When you start Solr in the background, the script will wait to make sure Solr starts correctly before returning to the command line prompt.
+
+The `bin/solr` and `bin\solr.cmd` scripts allow you to customize how you start Solr. Let's work through a few examples of using the `bin/solr` script (if you're running Solr on Windows, the `bin\solr.cmd` works the same as what is shown in the examples below):
+
+[[RunningSolr-SolrScriptOptions]]
+=== Solr Script Options
+
+The `bin/solr` script has several options.
+
+[[RunningSolr-ScriptHelp]]
+==== Script Help
+
+To see how to use the `bin/solr` script, execute:
+
+[source,bash]
+----
+bin/solr -help
+----
+
+For specific usage instructions for the *start* command, do:
+
+[source,bash]
+----
+bin/solr start -help
+----
+
+[[RunningSolr-StartSolrintheForeground]]
+==== Start Solr in the Foreground
+
+Since Solr is a server, it is more common to run it in the background, especially on Unix/Linux. However, to start Solr in the foreground, simply do:
+
+[source,bash]
+----
+bin/solr start -f
+----
+
+If you are running Windows, you can run:
+
+[source,plain]
+----
+bin\solr.cmd start -f
+----
+
+[[RunningSolr-StartSolrwithaDifferentPort]]
+==== Start Solr with a Different Port
+
+To change the port Solr listens on, you can use the `-p` parameter when starting, such as:
+
+[source,bash]
+----
+bin/solr start -p 8984
+----
+
+[[RunningSolr-StopSolr]]
+==== Stop Solr
+
+When running Solr in the foreground (using -f), then you can stop it using `Ctrl-c`. However, when running in the background, you should use the *stop* command, such as:
+
+[source,bash]
+----
+bin/solr stop -p 8983
+----
+
+The stop command requires you to specify the port Solr is listening on or you can use the `-all` parameter to stop all running Solr instances.
+
+[[RunningSolr-StartSolrwithaSpecificBundledExample]]
+==== Start Solr with a Specific Bundled Example
+
+Solr also provides a number of useful examples to help you learn about key features. You can launch the examples using the `-e` flag. For instance, to launch the "techproducts" example, you would do:
+
+[source,bash]
+----
+bin/solr -e techproducts
+----
+
+Currently, the available examples you can run are: techproducts, dih, schemaless, and cloud. See the section <<solr-control-script-reference.adoc#SolrControlScriptReference-RunningwithExampleConfigurations,Running with Example Configurations>> for details on each example.
+
+.Getting Started with SolrCloud
+[NOTE]
+====
+Running the `cloud` example starts Solr in <<solrcloud.adoc#solrcloud,SolrCloud>> mode. For more information on starting Solr in cloud mode, see the section <<getting-started-with-solrcloud.adoc#getting-started-with-solrcloud,Getting Started with SolrCloud>>.
+====
+
+[[RunningSolr-CheckifSolrisRunning]]
+==== Check if Solr is Running
+
+If you're not sure if Solr is running locally, you can use the status command:
+
+[source,bash]
+----
+bin/solr status
+----
+
+This will search for running Solr instances on your computer and then gather basic information about them, such as the version and memory usage.
+
+That's it! Solr is running. If you need convincing, use a Web browser to see the Admin Console.
+
+`\http://localhost:8983/solr/`
+
+.The Solr Admin interface.
+image::images/running-solr/SolrAdminDashboard.png[image,width=900,height=456]
+
+If Solr is not running, your browser will complain that it cannot connect to the server. Check your port number and try again.
+
+[[RunningSolr-CreateaCore]]
+== Create a Core
+
+If you did not start Solr with an example configuration, you would need to create a core in order to be able to index and search. You can do so by running:
+
+[source,bash]
+----
+bin/solr create -c <name>
+----
+
+This will create a core that uses a data-driven schema which tries to guess the correct field type when you add documents to the index.
+
+To see all available options for creating a new core, execute:
+
+[source,bash]
+----
+bin/solr create -help
+----
+
+[[RunningSolr-AddDocuments]]
+== Add Documents
+
+Solr is built to find documents that match queries. Solr's schema provides an idea of how content is structured (more on the schema <<documents-fields-and-schema-design.adoc#documents-fields-and-schema-design,later>>), but without documents there is nothing to find. Solr needs input before it can do much.
+
+You may want to add a few sample documents before trying to index your own content. The Solr installation comes with different types of example documents located under the sub-directories of the `example/` directory of your installation.
+
+In the `bin/` directory is the post script, a command line tool which can be used to index different types of documents. Do not worry too much about the details for now. The <<indexing-and-basic-data-operations.adoc#indexing-and-basic-data-operations,Indexing and Basic Data Operations>> section has all the details on indexing.
+
+To see some information about the usage of `bin/post`, use the `-help` option. Windows users, see the section for <<post-tool.adoc#PostTool-WindowsSupport,Post Tool on Windows>>.
+
+`bin/post` can post various types of content to Solr, including files in Solr's native XML and JSON formats, CSV files, a directory tree of rich documents, or even a simple short web crawl. See the examples at the end of `bin/post -help` for various commands to easily get started posting your content into Solr.
+
+Go ahead and add all the documents in some example XML files:
+
+[source,plain]
+----
+$ bin/post -c gettingstarted example/exampledocs/*.xml
+SimplePostTool version 5.0.0
+Posting files to [base] url http://localhost:8983/solr/gettingstarted/update...
+Entering auto mode. File endings considered are xml,json,csv,pdf,doc,docx,ppt,pptx,xls,xlsx,odt,odp,ods,ott,otp,ots,rtf,htm,html,txt,log
+POSTing file gb18030-example.xml (application/xml) to [base]
+POSTing file hd.xml (application/xml) to [base]
+POSTing file ipod_other.xml (application/xml) to [base]
+POSTing file ipod_video.xml (application/xml) to [base]
+POSTing file manufacturers.xml (application/xml) to [base]
+POSTing file mem.xml (application/xml) to [base]
+POSTing file money.xml (application/xml) to [base]
+POSTing file monitor.xml (application/xml) to [base]
+POSTing file monitor2.xml (application/xml) to [base]
+POSTing file mp500.xml (application/xml) to [base]
+POSTing file sd500.xml (application/xml) to [base]
+POSTing file solr.xml (application/xml) to [base]
+POSTing file utf8-example.xml (application/xml) to [base]
+POSTing file vidcard.xml (application/xml) to [base]
+14 files indexed.
+COMMITting Solr index changes to http://localhost:8983/solr/gettingstarted/update...
+Time spent: 0:00:00.153
+----
+
+That's it! Solr has indexed the documents contained in those files.
+
+[[RunningSolr-AskQuestions]]
+== Ask Questions
+
+Now that you have indexed documents, you can perform queries. The simplest way is by building a URL that includes the query parameters. This is exactly the same as building any other HTTP URL.
+
+For example, the following query searches all document fields for "video":
+
+`\http://localhost:8983/solr/gettingstarted/select?q=video`
+
+Notice how the URL includes the host name (`localhost`), the port number where the server is listening (`8983`), the application name (`solr`), the request handler for queries (`select`), and finally, the query itself (`q=video`).
+
+The results are contained in an XML document, which you can examine directly by clicking on the link above. The document contains two parts. The first part is the `responseHeader`, which contains information about the response itself. The main part of the reply is in the result tag, which contains one or more doc tags, each of which contains fields from documents that match the query. You can use standard XML transformation techniques to mold Solr's results into a form that is suitable for displaying to users. Alternatively, Solr can output the results in JSON, PHP, Ruby and even user-defined formats.
+
+Just in case you are not running Solr as you read, the following screen shot shows the result of a query (the next example, actually) as viewed in Mozilla Firefox. The top-level response contains a `lst` named `responseHeader` and a result named response. Inside result, you can see the three docs that represent the search results.
+
+.An XML response to a query.
+image::images/running-solr/solr34_responseHeader.png[image,width=600,height=634]
+
+Once you have mastered the basic idea of a query, it is easy to add enhancements to explore the query syntax. This one is the same as before but the results only contain the ID, name, and price for each returned document. If you don't specify which fields you want, all of them are returned.
+
+`\http://localhost:8983/solr/gettingstarted/select?q=video&fl=id,name,price`
+
+Here is another example which searches for "black" in the `name` field only. If you do not tell Solr which field to search, it will search default fields, as specified in the schema.
+
+`\http://localhost:8983/solr/gettingstarted/select?q=name:black`
+
+You can provide ranges for fields. The following query finds every document whose price is between $0 and $400.
+
+`\http://localhost:8983/solr/gettingstarted/select?q=price:[0%20TO%20400]&fl=id,name,price`
+
+<<faceting.adoc#faceting,Faceted browsing>> is one of Solr's key features. It allows users to narrow search results in ways that are meaningful to your application. For example, a shopping site could provide facets to narrow search results by manufacturer or price.
+
+Faceting information is returned as a third part of Solr's query response. To get a taste of this power, take a look at the following query. It adds `facet=true` and `facet.field=cat`.
+
+`\http://localhost:8983/solr/gettingstarted/select?q=price:[0%20TO%20400]&fl=id,name,price&facet=true&facet.field=cat`
+
+In addition to the familiar `responseHeader` and response from Solr, a `facet_counts` element is also present. Here is a view with the `responseHeader` and response collapsed so you can see the faceting information clearly.
+
+*An XML Response with faceting*
+
+[source,xml]
+----
+<response>
+<lst name="responseHeader">
+...
+</lst>
+<result name="response" numFound="9" start="0">
+ <doc>
+ <str name="id">SOLR1000</str>
+ <str name="name">Solr, the Enterprise Search Server</str>
+ <float name="price">0.0</float></doc>
+...
+</result>
+<lst name="facet_counts">
+ <lst name="facet_queries"/>
+ <lst name="facet_fields">
+ <lst name="cat">
+ <int name="electronics">6</int>
+ <int name="memory">3</int>
+ <int name="search">2</int>
+ <int name="software">2</int>
+ <int name="camera">1</int>
+ <int name="copier">1</int>
+ <int name="multifunction printer">1</int>
+ <int name="music">1</int>
+ <int name="printer">1</int>
+ <int name="scanner">1</int>
+ <int name="connector">0</int>
+ <int name="currency">0</int>
+ <int name="graphics card">0</int>
+ <int name="hard drive">0</int>
+ <int name="monitor">0</int>
+ </lst>
+ </lst>
+ <lst name="facet_dates"/>
+ <lst name="facet_ranges"/>
+</lst>
+</response>
+----
+
+The facet information shows how many of the query results have each possible value of the `cat` field. You could easily use this information to provide users with a quick way to narrow their query results. You can filter results by adding one or more filter queries to the Solr request. This request constrains documents with a category of "software".
+
+`\http://localhost:8983/solr/gettingstarted/select?q=price:0%20TO%20400&fl=id,name,price&facet=true&facet.field=cat&fq=cat:software`
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/c8c2aab8/solr/solr-ref-guide/src/running-your-analyzer.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/running-your-analyzer.adoc b/solr/solr-ref-guide/src/running-your-analyzer.adoc
new file mode 100644
index 0000000..c143d7f
--- /dev/null
+++ b/solr/solr-ref-guide/src/running-your-analyzer.adoc
@@ -0,0 +1,42 @@
+= Running Your Analyzer
+:page-shortname: running-your-analyzer
+:page-permalink: running-your-analyzer.html
+
+Once you've <<field-type-definitions-and-properties.adoc#field-type-definitions-and-properties,defined a field type in your Schema>>, and specified the analysis steps that you want applied to it, you should test it out to make sure that it behaves the way you expect it to.
+
+Luckily, there is a very handy page in the Solr <<using-the-solr-administration-user-interface.adoc#using-the-solr-administration-user-interface,admin interface>> that lets you do just that. You can invoke the analyzer for any text field, provide sample input, and display the resulting token stream.
+
+For example, let's look at some of the "Text" field types available in the `bin/solr -e techproducts` example configuration, and use the <<analysis-screen.adoc#analysis-screen,Analysis Screen>> (`\http://localhost:8983/solr/#/techproducts/analysis`) to compare how the tokens produced at index time for the sentence "Running an Analyzer" match up with a slightly different query text of "run my analyzer"
+
+We can begin with "```text_ws```" - one of the most simplified Text field types available:
+
+image::images/running-your-analyzer/analysis_compare_0.png[image]
+
+By looking at the start and end positions for each term, we can see that the only thing this field type does is tokenize text on whitespace. Notice in this image that the term "Running" has a start position of 0 and an end position of 7, while "an" has a start position of 8 and an end position of 10, and "Analyzer" starts at 11 and ends at 19. If the whitespace between the terms was also included, the count would be 21; since it is 19, we know that whitespace has been removed from this query.
+
+Note also that the indexed terms and the query terms are still very different. "Running" doesn't match "run", "Analyzer" doesn't match "analyzer" (to a computer), and obviously "an" and "my" are totally different words. If our objective is to allow queries like "run my analyzer" to match indexed text like "Running an Analyzer" then we will evidently need to pick a different field type with index & query time text analysis that does more processing of the inputs.
+
+In particular we will want:
+
+* Case insensitivity, so "Analyzer" and "analyzer" match.
+* Stemming, so words like "Run" and "Running" are considered equivalent terms.
+* Stop Word Pruning, so small words like "an" and "my" don't affect the query.
+
+For our next attempt, let's try the "```text_general```" field type:
+
+image::images/running-your-analyzer/analysis_compare_1.png[image]
+
+With the verbose output enabled, we can see how each stage of our new analyzers modify the tokens they receive before passing them on to the next stage. As we scroll down to the final output, we can see that we do start to get a match on "analyzer" from each input string, thanks to the "LCF" stage -- which if you hover over with your mouse, you'll see is the "```LowerCaseFilter```":
+
+image::images/running-your-analyzer/analysis_compare_2.png[image]
+
+The "```text_general```" field type is designed to be generally useful for any language, and it has definitely gotten us closer to our objective than "```text_ws```" from our first example by solving the problem of case sensitivity. It's still not quite what we are looking for because we don't see stemming or stopword rules being applied. So now let us try the "```text_en```" field type:
+
+image::images/running-your-analyzer/analysis_compare_3.png[image]
+
+Now we can see the "SF" (`StopFilter`) stage of the analyzers solving the problem of removing Stop Words ("an"), and as we scroll down, we also see the "PSF" (`PorterStemFilter`) stage apply stemming rules suitable for our English language input, such that the terms produced by our "index analyzer" and the terms produced by our "query analyzer" match the way we expect.
+
+image::images/running-your-analyzer/analysis_compare_4.png[image]
+
+
+At this point, we can continue to experiment with additional inputs, verifying that our analyzers produce matching tokens when we expect them to match, and disparate tokens when we do not expect them to match, as we iterate and tweak our field type configuration.
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/c8c2aab8/solr/solr-ref-guide/src/schema-api.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/schema-api.adoc b/solr/solr-ref-guide/src/schema-api.adoc
new file mode 100644
index 0000000..f1ea86b
--- /dev/null
+++ b/solr/solr-ref-guide/src/schema-api.adoc
@@ -0,0 +1,1228 @@
+= Schema API
+:page-shortname: schema-api
+:page-permalink: schema-api.html
+
+The Schema API allows you to use an HTTP API to manage many of the elements of your schema.
+
+The Schema API utilizes the ManagedIndexSchemaFactory class, which is the default schema factory in modern Solr versions. See the section <<schema-factory-definition-in-solrconfig.adoc#schema-factory-definition-in-solrconfig,Schema Factory Definition in SolrConfig>> for more information about choosing a schema factory for your index.
+
+This API provides read and write access to the Solr schema for each collection (or core, when using standalone Solr). Read access to all schema elements is supported. Fields, dynamic fields, field types and copyField rules may be added, removed or replaced. Future Solr releases will extend write access to allow more schema elements to be modified.
+
+.Why is hand editing of the managed schema discouraged?
+[NOTE]
+====
+The file named "managed-schema" in the example configurations may include a note that recommends never hand-editing the file. Before the Schema API existed, such edits were the only way to make changes to the schema, and users may have a strong desire to continue making changes this way.
+
+The reason that this is discouraged is because hand-edits of the schema may be lost if the Schema API described here is later used to make a change, unless the core or collection is reloaded or Solr is restarted before using the Schema API. If care is taken to always reload or restart after a manual edit, then there is no problem at all with doing those edits.
+====
+
+The API allows two output modes for all calls: JSON or XML. When requesting the complete schema, there is another output mode which is XML modeled after the managed-schema file itself, which is in XML format.
+
+When modifying the schema with the API, a core reload will automatically occur in order for the changes to be available immediately for documents indexed thereafter. Previously indexed documents will *not* be automatically updated - they *must* be re-indexed if existing index data uses schema elements that you changed.
+
+.Re-index after schema modifications!
+[IMPORTANT]
+====
+If you modify your schema, you will likely need to re-index all documents. If you do not, you may lose access to documents, or not be able to interpret them properly, e.g. after replacing a field type.
+
+Modifying your schema will never modify any documents that are already indexed. You must re-index documents in order to apply schema changes to them. Queries and updates made after the change may encounter errors that were not present before the change. Completely deleting the index and rebuilding it is usually the only option to fix such errors.
+====
+
+The base address for the API is `\http://<host>:<port>/solr/<collection_name>`. If, for example, you run Solr's "```cloud```" example (via the `bin/solr` command shown below), which creates a "```gettingstarted```" collection, then the base URL for that collection (as in all the sample URLs in this section) would be: `\http://localhost:8983/solr/gettingstarted`.
+
+[source,bash]
+----
+bin/solr -e cloud -noprompt
+----
+
+[[SchemaAPI-APIEntryPoints]]
+== API Entry Points
+
+* `/schema`: <<SchemaAPI-RetrievetheEntireSchema,retrieve>> the schema, or <<SchemaAPI-ModifytheSchema,modify>> the schema to add, remove, or replace fields, dynamic fields, copy fields, or field types
+* `/schema/fields`: <<SchemaAPI-ListFields,retrieve information>> about all defined fields or a specific named field
+* `/schema/dynamicfields`: <<SchemaAPI-ListDynamicFields,retrieve information>> about all dynamic field rules or a specific named dynamic rule
+* `/schema/fieldtypes`: <<SchemaAPI-ListFieldTypes,retrieve information>> about all field types or a specific field type
+* `/schema/copyfields`: <<SchemaAPI-ListCopyFields,retrieve information>> about copy fields
+* `/schema/name`: <<SchemaAPI-ShowSchemaName,retrieve>> the schema name
+* `/schema/version`: <<SchemaAPI-ShowtheSchemaVersion,retrieve>> the schema version
+* `/schema/uniquekey`: <<SchemaAPI-ListUniqueKey,retrieve>> the defined uniqueKey
+* `/schema/similarity`: <<SchemaAPI-ShowGlobalSimilarity,retrieve>> the global similarity definition
+* `/schema/solrqueryparser/defaultoperator`: <<SchemaAPI-GettheDefaultQueryOperator,retrieve>> the default operator
+
+[[SchemaAPI-ModifytheSchema]]
+== Modify the Schema
+
+`POST /_collection_/schema`
+
+To add, remove or replace fields, dynamic field rules, copy field rules, or new field types, you can send a POST request to the `/collection/schema/` endpoint with a sequence of commands to perform the requested actions. The following commands are supported:
+
+* `add-field`: add a new field with parameters you provide.
+* `delete-field`: delete a field.
+* `replace-field`: replace an existing field with one that is differently configured.
+* `add-dynamic-field`: add a new dynamic field rule with parameters you provide.
+* `delete-dynamic-field`: delete a dynamic field rule.
+* `replace-dynamic-field`: replace an existing dynamic field rule with one that is differently configured.
+* `add-field-type`: add a new field type with parameters you provide.
+* `delete-field-type`: delete a field type.
+* `replace-field-type`: replace an existing field type with one that is differently configured.
+* `add-copy-field`: add a new copy field rule.
+* `delete-copy-field`: delete a copy field rule.
+
+These commands can be issued in separate POST requests or in the same POST request. Commands are executed in the order in which they are specified.
+
+In each case, the response will include the status and the time to process the request, but will not include the entire schema.
+
+When modifying the schema with the API, a core reload will automatically occur in order for the changes to be available immediately for documents indexed thereafter. Previously indexed documents will *not* be automatically handled - they *must* be re-indexed if they used schema elements that you changed.
+
+[[SchemaAPI-AddaNewField]]
+=== Add a New Field
+
+The `add-field` command adds a new field definition to your schema. If a field with the same name exists an error is thrown.
+
+All of the properties available when defining a field with manual `schema.xml` edits can be passed via the API. These request attributes are described in detail in the section <<defining-fields.adoc#defining-fields,Defining Fields>>.
+
+For example, to define a new stored field named "sell-by", of type "tdate", you would POST the following request:
+
+[source,bash]
+----
+curl -X POST -H 'Content-type:application/json' --data-binary '{
+ "add-field":{
+ "name":"sell-by",
+ "type":"tdate",
+ "stored":true }
+}' http://localhost:8983/solr/gettingstarted/schema
+----
+
+[[SchemaAPI-DeleteaField]]
+=== Delete a Field
+
+The `delete-field` command removes a field definition from your schema. If the field does not exist in the schema, or if the field is the source or destination of a copy field rule, an error is thrown.
+
+For example, to delete a field named "sell-by", you would POST the following request:
+
+[source,bash]
+----
+curl -X POST -H 'Content-type:application/json' --data-binary '{
+ "delete-field" : { "name":"sell-by" }
+}' http://localhost:8983/solr/gettingstarted/schema
+----
+
+[[SchemaAPI-ReplaceaField]]
+=== Replace a Field
+
+The `replace-field` command replaces a field's definition. Note that you must supply the full definition for a field - this command will *not* partially modify a field's definition. If the field does not exist in the schema an error is thrown.
+
+All of the properties available when defining a field with manual `schema.xml` edits can be passed via the API. These request attributes are described in detail in the section <<defining-fields.adoc#defining-fields,Defining Fields>>.
+
+For example, to replace the definition of an existing field "sell-by", to make it be of type "date" and to not be stored, you would POST the following request:
+
+[source,bash]
+----
+curl -X POST -H 'Content-type:application/json' --data-binary '{
+ "replace-field":{
+ "name":"sell-by",
+ "type":"date",
+ "stored":false }
+}' http://localhost:8983/solr/gettingstarted/schema
+----
+
+[[SchemaAPI-AddaDynamicFieldRule]]
+=== Add a Dynamic Field Rule
+
+The `add-dynamic-field` command adds a new dynamic field rule to your schema.
+
+All of the properties available when editing `schema.xml` can be passed with the POST request. The section <<dynamic-fields.adoc#dynamic-fields,Dynamic Fields>> has details on all of the attributes that can be defined for a dynamic field rule.
+
+For example, to create a new dynamic field rule where all incoming fields ending with "_s" would be stored and have field type "string", you can POST a request like this:
+
+[source,bash]
+----
+curl -X POST -H 'Content-type:application/json' --data-binary '{
+ "add-dynamic-field":{
+ "name":"*_s",
+ "type":"string",
+ "stored":true }
+}' http://localhost:8983/solr/gettingstarted/schema
+----
+
+[[SchemaAPI-DeleteaDynamicFieldRule]]
+=== Delete a Dynamic Field Rule
+
+The `delete-dynamic-field` command deletes a dynamic field rule from your schema. If the dynamic field rule does not exist in the schema, or if the schema contains a copy field rule with a target or destination that matches only this dynamic field rule, an error is thrown.
+
+For example, to delete a dynamic field rule matching "*_s", you can POST a request like this:
+
+[source,bash]
+----
+curl -X POST -H 'Content-type:application/json' --data-binary '{
+ "delete-dynamic-field":{ "name":"*_s" }
+}' http://localhost:8983/solr/gettingstarted/schema
+----
+
+[[SchemaAPI-ReplaceaDynamicFieldRule]]
+=== Replace a Dynamic Field Rule
+
+The `replace-dynamic-field` command replaces a dynamic field rule in your schema. Note that you must supply the full definition for a dynamic field rule - this command will *not* partially modify a dynamic field rule's definition. If the dynamic field rule does not exist in the schema an error is thrown.
+
+All of the properties available when editing `schema.xml` can be passed with the POST request. The section <<dynamic-fields.adoc#dynamic-fields,Dynamic Fields>> has details on all of the attributes that can be defined for a dynamic field rule.
+
+For example, to replace the definition of the "*_s" dynamic field rule with one where the field type is "text_general" and it's not stored, you can POST a request like this:
+
+[source,bash]
+----
+curl -X POST -H 'Content-type:application/json' --data-binary '{
+ "replace-dynamic-field":{
+ "name":"*_s",
+ "type":"text_general",
+ "stored":false }
+}' http://localhost:8983/solr/gettingstarted/schema
+----
+
+[[SchemaAPI-AddaNewFieldType]]
+=== Add a New Field Type
+
+The `add-field-type` command adds a new field type to your schema.
+
+All of the field type properties available when editing `schema.xml` by hand are available for use in a POST request. The structure of the command is a json mapping of the standard field type definition, including the name, class, index and query analyzer definitions, etc. Details of all of the available options are described in the section <<solr-field-types.adoc#solr-field-types,Solr Field Types>>.
+
+For example, to create a new field type named "myNewTxtField", you can POST a request as follows:
+
+[source,bash]
+----
+curl -X POST -H 'Content-type:application/json' --data-binary '{
+ "add-field-type" : {
+ "name":"myNewTxtField",
+ "class":"solr.TextField",
+ "positionIncrementGap":"100",
+ "analyzer" : {
+ "charFilters":[{
+ "class":"solr.PatternReplaceCharFilterFactory",
+ "replacement":"$1$1",
+ "pattern":"([a-zA-Z])\\\\1+" }],
+ "tokenizer":{
+ "class":"solr.WhitespaceTokenizerFactory" },
+ "filters":[{
+ "class":"solr.WordDelimiterFilterFactory",
+ "preserveOriginal":"0" }]}}
+}' http://localhost:8983/solr/gettingstarted/schema
+----
+
+Note in this example that we have only defined a single analyzer section that will apply to index analysis and query analysis. If we wanted to define separate analysis, we would replace the `analyzer` section in the above example with separate sections for `indexAnalyzer` and `queryAnalyzer`. As in this example:
+
+[source,bash]
+----
+curl -X POST -H 'Content-type:application/json' --data-binary '{
+ "add-field-type":{
+ "name":"myNewTextField",
+ "class":"solr.TextField",
+ "indexAnalyzer":{
+ "tokenizer":{
+ "class":"solr.PathHierarchyTokenizerFactory",
+ "delimiter":"/" }},
+ "queryAnalyzer":{
+ "tokenizer":{
+ "class":"solr.KeywordTokenizerFactory" }}}
+}' http://localhost:8983/solr/gettingstarted/schema
+----
+
+[[SchemaAPI-DeleteaFieldType]]
+=== Delete a Field Type
+
+The `delete-field-type` command removes a field type from your schema. If the field type does not exist in the schema, or if any field or dynamic field rule in the schema uses the field type, an error is thrown.
+
+For example, to delete the field type named "myNewTxtField", you can make a POST request as follows:
+
+[source,bash]
+----
+curl -X POST -H 'Content-type:application/json' --data-binary '{
+ "delete-field-type":{ "name":"myNewTxtField" }
+}' http://localhost:8983/solr/gettingstarted/schema
+----
+
+[[SchemaAPI-ReplaceaFieldType]]
+=== Replace a Field Type
+
+The `replace-field-type` command replaces a field type in your schema. Note that you must supply the full definition for a field type - this command will *not* partially modify a field type's definition. If the field type does not exist in the schema an error is thrown.
+
+All of the field type properties available when editing `schema.xml` by hand are available for use in a POST request. The structure of the command is a json mapping of the standard field type definition, including the name, class, index and query analyzer definitions, etc. Details of all of the available options are described in the section <<solr-field-types.adoc#solr-field-types,Solr Field Types>>.
+
+For example, to replace the definition of a field type named "myNewTxtField", you can make a POST request as follows:
+
+[source,bash]
+----
+curl -X POST -H 'Content-type:application/json' --data-binary '{
+ "replace-field-type":{
+ "name":"myNewTxtField",
+ "class":"solr.TextField",
+ "positionIncrementGap":"100",
+ "analyzer":{
+ "tokenizer":{
+ "class":"solr.StandardTokenizerFactory" }}}
+}' http://localhost:8983/solr/gettingstarted/schema
+----
+
+[[SchemaAPI-AddaNewCopyFieldRule]]
+=== Add a New Copy Field Rule
+
+The `add-copy-field` command adds a new copy field rule to your schema.
+
+The attributes supported by the command are the same as when creating copy field rules by manually editing the `schema.xml`, as below:
+
+// TODO: Change column width to %autowidth.spread when https://github.com/asciidoctor/asciidoctor-pdf/issues/599 is fixed
+
+[cols="20,20,60",options="header"]
+|===
+|Name |Required |Description
+|source |Yes |The source field.
+|dest |Yes |A field or an array of fields to which the source field will be copied.
+|maxChars |No |The upper limit for the number of characters to be copied. The section <<copying-fields.adoc#copying-fields,Copying Fields>> has more details.
+|===
+
+For example, to define a rule to copy the field "shelf" to the "location" and "catchall" fields, you would POST the following request:
+
+[source,bash]
+----
+curl -X POST -H 'Content-type:application/json' --data-binary '{
+ "add-copy-field":{
+ "source":"shelf",
+ "dest":[ "location", "catchall" ]}
+}' http://localhost:8983/solr/gettingstarted/schema
+----
+
+[[SchemaAPI-DeleteaCopyFieldRule]]
+=== Delete a Copy Field Rule
+
+The `delete-copy-field` command deletes a copy field rule from your schema. If the copy field rule does not exist in the schema an error is thrown.
+
+The `source` and `dest` attributes are required by this command.
+
+For example, to delete a rule to copy the field "shelf" to the "location" field, you would POST the following request:
+
+[source,bash]
+----
+curl -X POST -H 'Content-type:application/json' --data-binary '{
+ "delete-copy-field":{ "source":"shelf", "dest":"location" }
+}' http://localhost:8983/solr/gettingstarted/schema
+----
+
+[[SchemaAPI-MultipleCommandsinaSinglePOST]]
+=== Multiple Commands in a Single POST
+
+It is possible to perform one or more add requests in a single command. The API is transactional and all commands in a single call either succeed or fail together.
+
+The commands are executed in the order in which they are specified. This means that if you want to create a new field type and in the same request use the field type on a new field, the section of the request that creates the field type must come before the section that creates the new field. Similarly, since a field must exist for it to be used in a copy field rule, a request to add a field must come before a request for the field to be used as either the source or the destination for a copy field rule.
+
+The syntax for making multiple requests supports several approaches. First, the commands can simply be made serially, as in this request to create a new field type and then a field that uses that type:
+
+[source,bash]
+----
+curl -X POST -H 'Content-type:application/json' --data-binary '{
+ "add-field-type":{
+ "name":"myNewTxtField",
+ "class":"solr.TextField",
+ "positionIncrementGap":"100",
+ "analyzer":{
+ "charFilters":[{
+ "class":"solr.PatternReplaceCharFilterFactory",
+ "replacement":"$1$1",
+ "pattern":"([a-zA-Z])\\\\1+" }],
+ "tokenizer":{
+ "class":"solr.WhitespaceTokenizerFactory" },
+ "filters":[{
+ "class":"solr.WordDelimiterFilterFactory",
+ "preserveOriginal":"0" }]}},
+ "add-field" : {
+ "name":"sell-by",
+ "type":"myNewTxtField",
+ "stored":true }
+}' http://localhost:8983/solr/gettingstarted/schema
+----
+
+Or, the same command can be repeated, as in this example:
+
+[source,bash]
+----
+curl -X POST -H 'Content-type:application/json' --data-binary '{
+ "add-field":{
+ "name":"shelf",
+ "type":"myNewTxtField",
+ "stored":true },
+ "add-field":{
+ "name":"location",
+ "type":"myNewTxtField",
+ "stored":true },
+ "add-copy-field":{
+ "source":"shelf",
+ "dest":[ "location", "catchall" ]}
+}' http://localhost:8983/solr/gettingstarted/schema
+----
+
+Finally, repeated commands can be sent as an array:
+
+[source,bash]
+----
+curl -X POST -H 'Content-type:application/json' --data-binary '{
+ "add-field":[
+ { "name":"shelf",
+ "type":"myNewTxtField",
+ "stored":true },
+ { "name":"location",
+ "type":"myNewTxtField",
+ "stored":true }]
+}' http://localhost:8983/solr/gettingstarted/schema
+----
+
+[[SchemaAPI-SchemaChangesamongReplicas]]
+=== Schema Changes among Replicas
+
+When running in SolrCloud mode, changes made to the schema on one node will propagate to all replicas in the collection.
+
+You can pass the `updateTimeoutSecs` parameter with your request to set the number of seconds to wait until all replicas confirm they applied the schema updates. This helps your client application be more robust in that you can be sure that all replicas have a given schema change within a defined amount of time.
+
+If agreement is not reached by all replicas in the specified time, then the request fails and the error message will include information about which replicas had trouble. In most cases, the only option is to re-try the change after waiting a brief amount of time. If the problem persists, then you'll likely need to investigate the server logs on the replicas that had trouble applying the changes.
+
+If you do not supply an `updateTimeoutSecs` parameter, the default behavior is for the receiving node to return immediately after persisting the updates to ZooKeeper. All other replicas will apply the updates asynchronously. Consequently, without supplying a timeout, your client application cannot be sure that all replicas have applied the changes.
+
+[[SchemaAPI-RetrieveSchemaInformation]]
+== Retrieve Schema Information
+
+The following endpoints allow you to read how your schema has been defined. You can GET the entire schema, or only portions of it as needed.
+
+To modify the schema, see the previous section <<SchemaAPI-ModifytheSchema,Modify the Schema>>.
+
+[[SchemaAPI-RetrievetheEntireSchema]]
+=== Retrieve the Entire Schema
+
+`GET /_collection_/schema`
+
+[[SchemaAPI-INPUT]]
+==== INPUT
+
+*Path Parameters*
+
+
+[options="header",]
+|===
+|Key |Description
+|collection |The collection (or core) name.
+|===
+
+*Query Parameters*
+
+The query parameters should be added to the API request after '?'.
+
+// TODO: Change column width to %autowidth.spread when https://github.com/asciidoctor/asciidoctor-pdf/issues/599 is fixed
+
+[cols="10,20,10,10,50",options="header"]
+|===
+|Key |Type |Required |Default |Description
+|wt |string |No |json |Defines the format of the response. The options are *json*, *xml* or *schema.xml*. If not specified, JSON will be returned by default.
+|===
+
+[[SchemaAPI-OUTPUT]]
+==== OUTPUT
+
+*Output Content*
+
+The output will include all fields, field types, dynamic rules and copy field rules, in the format requested (JSON or XML). The schema name and version are also included.
+
+[[SchemaAPI-EXAMPLES]]
+==== EXAMPLES
+
+Get the entire schema in JSON.
+
+[source,bash]
+----
+curl http://localhost:8983/solr/gettingstarted/schema?wt=json
+----
+
+[source,json]
+----
+{
+ "responseHeader":{
+ "status":0,
+ "QTime":5},
+ "schema":{
+ "name":"example",
+ "version":1.5,
+ "uniqueKey":"id",
+ "fieldTypes":[{
+ "name":"alphaOnlySort",
+ "class":"solr.TextField",
+ "sortMissingLast":true,
+ "omitNorms":true,
+ "analyzer":{
+ "tokenizer":{
+ "class":"solr.KeywordTokenizerFactory"},
+ "filters":[{
+ "class":"solr.LowerCaseFilterFactory"},
+ {
+ "class":"solr.TrimFilterFactory"},
+ {
+ "class":"solr.PatternReplaceFilterFactory",
+ "replace":"all",
+ "replacement":"",
+ "pattern":"([^a-z])"}]}}],
+ "fields":[{
+ "name":"_version_",
+ "type":"long",
+ "indexed":true,
+ "stored":true},
+ {
+ "name":"author",
+ "type":"text_general",
+ "indexed":true,
+ "stored":true},
+ {
+ "name":"cat",
+ "type":"string",
+ "multiValued":true,
+ "indexed":true,
+ "stored":true}],
+ "copyFields":[{
+ "source":"author",
+ "dest":"text"},
+ {
+ "source":"cat",
+ "dest":"text"},
+ {
+ "source":"content",
+ "dest":"text"},
+ {
+ "source":"author",
+ "dest":"author_s"}]}}
+----
+
+Get the entire schema in XML.
+
+[source,bash]
+----
+curl http://localhost:8983/solr/gettingstarted/schema?wt=xml
+----
+
+[source,xml]
+----
+<response>
+<lst name="responseHeader">
+ <int name="status">0</int>
+ <int name="QTime">5</int>
+</lst>
+<lst name="schema">
+ <str name="name">example</str>
+ <float name="version">1.5</float>
+ <str name="uniqueKey">id</str>
+ <arr name="fieldTypes">
+ <lst>
+ <str name="name">alphaOnlySort</str>
+ <str name="class">solr.TextField</str>
+ <bool name="sortMissingLast">true</bool>
+ <bool name="omitNorms">true</bool>
+ <lst name="analyzer">
+ <lst name="tokenizer">
+ <str name="class">solr.KeywordTokenizerFactory</str>
+ </lst>
+ <arr name="filters">
+ <lst>
+ <str name="class">solr.LowerCaseFilterFactory</str>
+ </lst>
+ <lst>
+ <str name="class">solr.TrimFilterFactory</str>
+ </lst>
+ <lst>
+ <str name="class">solr.PatternReplaceFilterFactory</str>
+ <str name="replace">all</str>
+ <str name="replacement"/>
+ <str name="pattern">([^a-z])</str>
+ </lst>
+ </arr>
+ </lst>
+ </lst>
+...
+ <lst>
+ <str name="source">author</str>
+ <str name="dest">author_s</str>
+ </lst>
+ </arr>
+</lst>
+</response>
+----
+
+Get the entire schema in "schema.xml" format.
+
+[source,bash]
+----
+curl http://localhost:8983/solr/gettingstarted/schema?wt=schema.xml
+----
+
+[source,xml]
+----
+<schema name="example" version="1.5">
+ <uniqueKey>id</uniqueKey>
+ <types>
+ <fieldType name="alphaOnlySort" class="solr.TextField" sortMissingLast="true" omitNorms="true">
+ <analyzer>
+ <tokenizer class="solr.KeywordTokenizerFactory"/>
+ <filter class="solr.LowerCaseFilterFactory"/>
+ <filter class="solr.TrimFilterFactory"/>
+ <filter class="solr.PatternReplaceFilterFactory" replace="all" replacement="" pattern="([^a-z])"/>
+ </analyzer>
+ </fieldType>
+...
+ <copyField source="url" dest="text"/>
+ <copyField source="price" dest="price_c"/>
+ <copyField source="author" dest="author_s"/>
+</schema>
+----
+
+
+[[SchemaAPI-ListFields]]
+=== List Fields
+
+`GET /_collection_/schema/fields`
+
+`GET /_collection_/schema/fields/_fieldname_`
+
+[[SchemaAPI-INPUT.1]]
+==== INPUT
+
+*Path Parameters*
+
+// TODO: Change column width to %autowidth.spread when https://github.com/asciidoctor/asciidoctor-pdf/issues/599 is fixed
+
+[cols="30,70",options="header"]
+|===
+|Key |Description
+|collection |The collection (or core) name.
+|fieldname |The specific fieldname (if limiting request to a single field).
+|===
+
+*Query Parameters*
+
+The query parameters can be added to the API request after a '?'.
+
+// TODO: Change column width to %autowidth.spread when https://github.com/asciidoctor/asciidoctor-pdf/issues/599 is fixed
+
+[cols="15,15,10,20,40",options="header"]
+|===
+|Key |Type |Required |Default |Description
+|wt |string |No |json |Defines the format of the response. The options are *json* or *xml*. If not specified, JSON will be returned by default.
+|fl |string |No |(all fields) |Comma- or space-separated list of one or more fields to return. If not specified, all fields will be returned by default.
+|includeDynamic |boolean |No |false |If *true*, and if the *fl* query parameter is specified or the *fieldname* path parameter is used, matching dynamic fields are included in the response and identified with the *dynamicBase* property. If neither the *fl* query parameter nor the *fieldname* path parameter is specified, the *includeDynamic* query parameter is ignored. If *false*, matching dynamic fields will not be returned.
+|showDefaults |boolean |No |false |If *true*, all default field properties from each field's field type will be included in the response (e.g. *tokenized* for `solr.TextField`). If *false*, only explicitly specified field properties will be included.
+|===
+
+[[SchemaAPI-OUTPUT.1]]
+==== OUTPUT
+
+*Output Content*
+
+The output will include each field and any defined configuration for each field. The defined configuration can vary for each field, but will minimally include the field `name`, the `type`, if it is `indexed` and if it is `stored`. If `multiValued` is defined as either true or false (most likely true), that will also be shown. See the section <<defining-fields.adoc#defining-fields,Defining Fields>> for more information about each parameter.
+
+[[SchemaAPI-EXAMPLES.1]]
+==== EXAMPLES
+
+Get a list of all fields.
+
+[source,bash]
+----
+curl http://localhost:8983/solr/gettingstarted/schema/fields?wt=json
+----
+
+The sample output below has been truncated to only show a few fields.
+
+[source,json]
+----
+{
+ "fields": [
+ {
+ "indexed": true,
+ "name": "_version_",
+ "stored": true,
+ "type": "long"
+ },
+ {
+ "indexed": true,
+ "name": "author",
+ "stored": true,
+ "type": "text_general"
+ },
+ {
+ "indexed": true,
+ "multiValued": true,
+ "name": "cat",
+ "stored": true,
+ "type": "string"
+ },
+"..."
+ ],
+ "responseHeader": {
+ "QTime": 1,
+ "status": 0
+ }
+}
+----
+
+
+[[SchemaAPI-ListDynamicFields]]
+=== List Dynamic Fields
+
+`GET /_collection_/schema/dynamicfields`
+
+`GET /_collection_/schema/dynamicfields/_name_`
+
+[[SchemaAPI-INPUT.2]]
+==== INPUT
+
+*Path Parameters*
+
+[options="header",]
+|===
+|Key |Description
+|collection |The collection (or core) name.
+|name |The name of the dynamic field rule (if limiting request to a single dynamic field rule).
+|===
+
+*Query Parameters*
+
+The query parameters can be added to the API request after a '?'.
+
+// TODO: Change column width to %autowidth.spread when https://github.com/asciidoctor/asciidoctor-pdf/issues/599 is fixed
+
+[cols="15,10,10,10,55",options="header"]
+|===
+|Key |Type |Required |Default |Description
+|wt |string |No |json |Defines the format of the response. The options are *json,* *xml*. If not specified, JSON will be returned by default.
+|showDefaults |boolean |No |false |If *true*, all default field properties from each dynamic field's field type will be included in the response (e.g. *tokenized* for `solr.TextField`). If *false*, only explicitly specified field properties will be included.
+|===
+
+[[SchemaAPI-OUTPUT.2]]
+==== OUTPUT
+
+*Output Content*
+
+The output will include each dynamic field rule and the defined configuration for each rule. The defined configuration can vary for each rule, but will minimally include the dynamic field `name`, the `type`, if it is `indexed` and if it is `stored`. See the section <<dynamic-fields.adoc#dynamic-fields,Dynamic Fields>> for more information about each parameter.
+
+[[SchemaAPI-EXAMPLES.2]]
+==== EXAMPLES
+
+Get a list of all dynamic field declarations:
+
+[source,bash]
+----
+curl http://localhost:8983/solr/gettingstarted/schema/dynamicfields?wt=json
+----
+
+The sample output below has been truncated.
+
+[source,json]
+----
+{
+ "dynamicFields": [
+ {
+ "indexed": true,
+ "name": "*_coordinate",
+ "stored": false,
+ "type": "tdouble"
+ },
+ {
+ "multiValued": true,
+ "name": "ignored_*",
+ "type": "ignored"
+ },
+ {
+ "name": "random_*",
+ "type": "random"
+ },
+ {
+ "indexed": true,
+ "multiValued": true,
+ "name": "attr_*",
+ "stored": true,
+ "type": "text_general"
+ },
+ {
+ "indexed": true,
+ "multiValued": true,
+ "name": "*_txt",
+ "stored": true,
+ "type": "text_general"
+ }
+"..."
+ ],
+ "responseHeader": {
+ "QTime": 1,
+ "status": 0
+ }
+}
+----
+
+[[SchemaAPI-ListFieldTypes]]
+=== List Field Types
+
+`GET /_collection_/schema/fieldtypes`
+
+`GET /_collection_/schema/fieldtypes/_name_`
+
+[[SchemaAPI-INPUT.3]]
+==== INPUT
+
+*Path Parameters*
+
+// TODO: Change column width to %autowidth.spread when https://github.com/asciidoctor/asciidoctor-pdf/issues/599 is fixed
+
+[cols="30,70",options="header"]
+|===
+|Key |Description
+|collection |The collection (or core) name.
+|name |The name of the field type (if limiting request to a single field type).
+|===
+
+*Query Parameters*
+
+The query parameters can be added to the API request after a '?'.
+
+// TODO: Change column width to %autowidth.spread when https://github.com/asciidoctor/asciidoctor-pdf/issues/599 is fixed
+
+[cols="15,10,10,10,55",options="header"]
+|===
+|Key |Type |Required |Default |Description
+|wt |string |No |json |Defines the format of the response. The options are *json* or *xml*. If not specified, JSON will be returned by default.
+|showDefaults |boolean |No |false |If *true*, all default field properties from each field type will be included in the response (e.g. *tokenized* for `solr.TextField`). If *false*, only explicitly specified field properties will be included.
+|===
+
+[[SchemaAPI-OUTPUT.3]]
+==== OUTPUT
+
+*Output Content*
+
+The output will include each field type and any defined configuration for the type. The defined configuration can vary for each type, but will minimally include the field type `name` and the `class`. If query or index analyzers, tokenizers, or filters are defined, those will also be shown with other defined parameters. See the section <<solr-field-types.adoc#solr-field-types,Solr Field Types>> for more information about how to configure various types of fields.
+
+[[SchemaAPI-EXAMPLES.3]]
+==== EXAMPLES
+
+Get a list of all field types.
+
+[source,bash]
+----
+curl http://localhost:8983/solr/gettingstarted/schema/fieldtypes?wt=json
+----
+
+The sample output below has been truncated to show a few different field types from different parts of the list.
+
+[source,json]
+----
+{
+ "fieldTypes": [
+ {
+ "analyzer": {
+ "class": "solr.TokenizerChain",
+ "filters": [
+ {
+ "class": "solr.LowerCaseFilterFactory"
+ },
+ {
+ "class": "solr.TrimFilterFactory"
+ },
+ {
+ "class": "solr.PatternReplaceFilterFactory",
+ "pattern": "([^a-z])",
+ "replace": "all",
+ "replacement": ""
+ }
+ ],
+ "tokenizer": {
+ "class": "solr.KeywordTokenizerFactory"
+ }
+ },
+ "class": "solr.TextField",
+ "dynamicFields": [],
+ "fields": [],
+ "name": "alphaOnlySort",
+ "omitNorms": true,
+ "sortMissingLast": true
+ },
+ {
+ "class": "solr.TrieFloatField",
+ "dynamicFields": [
+ "*_fs",
+ "*_f"
+ ],
+ "fields": [
+ "price",
+ "weight"
+ ],
+ "name": "float",
+ "positionIncrementGap": "0",
+ "precisionStep": "0"
+ }]
+}
+----
+
+[[SchemaAPI-ListCopyFields]]
+=== List Copy Fields
+
+`GET /_collection_/schema/copyfields`
+
+[[SchemaAPI-INPUT.4]]
+==== INPUT
+
+*Path Parameters*
+
+// TODO: Change column width to %autowidth.spread when https://github.com/asciidoctor/asciidoctor-pdf/issues/599 is fixed
+
+[cols="30,70",options="header"]
+|===
+|Key |Description
+|collection |The collection (or core) name.
+|===
+
+*Query Parameters*
+
+The query parameters can be added to the API request after a '?'.
+
+// TODO: Change column width to %autowidth.spread when https://github.com/asciidoctor/asciidoctor-pdf/issues/599 is fixed
+
+[cols="15,10,10,10,55",options="header"]
+|===
+|Key |Type |Required |Default |Description
+|wt |string |No |json |Defines the format of the response. The options are *json* or *xml*. If not specified, JSON will be returned by default.
+|source.fl |string |No |(all source fields) |Comma- or space-separated list of one or more copyField source fields to include in the response - copyField directives with all other source fields will be excluded from the response. If not specified, all copyField-s will be included in the response.
+|dest.fl |string |No |(all dest fields) |Comma- or space-separated list of one or more copyField dest fields to include in the response - copyField directives with all other dest fields will be excluded. If not specified, all copyField-s will be included in the response.
+|===
+
+[[SchemaAPI-OUTPUT.4]]
+==== OUTPUT
+
+*Output Content*
+
+The output will include the `source` and `dest`ination of each copy field rule defined in `schema.xml`. For more information about copying fields, see the section <<copying-fields.adoc#copying-fields,Copying Fields>>.
+
+[[SchemaAPI-EXAMPLES.4]]
+==== EXAMPLES
+
+Get a list of all copyfields.
+
+[source,bash]
+----
+curl http://localhost:8983/solr/gettingstarted/schema/copyfields?wt=json
+----
+
+The sample output below has been truncated to the first few copy definitions.
+
+[source,json]
+----
+{
+ "copyFields": [
+ {
+ "dest": "text",
+ "source": "author"
+ },
+ {
+ "dest": "text",
+ "source": "cat"
+ },
+ {
+ "dest": "text",
+ "source": "content"
+ },
+ {
+ "dest": "text",
+ "source": "content_type"
+ },
+ ],
+ "responseHeader": {
+ "QTime": 3,
+ "status": 0
+ }
+}
+----
+
+
+[[SchemaAPI-ShowSchemaName]]
+=== Show Schema Name
+
+`GET /_collection_/schema/name`
+
+[[SchemaAPI-INPUT.5]]
+==== INPUT
+
+*Path Parameters*
+
+// TODO: Change column width to %autowidth.spread when https://github.com/asciidoctor/asciidoctor-pdf/issues/599 is fixed
+
+[cols="30,70",options="header"]
+|===
+|Key |Description
+|collection |The collection (or core) name.
+|===
+
+*Query Parameters*
+
+The query parameters can be added to the API request after a '?'.
+
+// TODO: Change column width to %autowidth.spread when https://github.com/asciidoctor/asciidoctor-pdf/issues/599 is fixed
+
+[cols="15,10,10,10,55",options="header"]
+|===
+|Key |Type |Required |Default |Description
+|wt |string |No |json |Defines the format of the response. The options are *json* or *xml*. If not specified, JSON will be returned by default.
+|===
+
+[[SchemaAPI-OUTPUT.5]]
+==== OUTPUT
+
+*Output Content* The output will be simply the name given to the schema.
+
+[[SchemaAPI-EXAMPLES.5]]
+==== EXAMPLES
+
+Get the schema name.
+
+[source,bash]
+----
+curl http://localhost:8983/solr/gettingstarted/schema/name?wt=json
+----
+
+[source,json]
+----
+{
+ "responseHeader":{
+ "status":0,
+ "QTime":1},
+ "name":"example"}
+----
+
+
+[[SchemaAPI-ShowtheSchemaVersion]]
+=== Show the Schema Version
+
+`GET /_collection_/schema/version`
+
+[[SchemaAPI-INPUT.6]]
+==== INPUT
+
+*Path Parameters*
+
+// TODO: Change column width to %autowidth.spread when https://github.com/asciidoctor/asciidoctor-pdf/issues/599 is fixed
+
+[cols="30,70",options="header"]
+|===
+|Key |Description
+|collection |The collection (or core) name.
+|===
+
+*Query Parameters*
+
+The query parameters can be added to the API request after a '?'.
+
+// TODO: Change column width to %autowidth.spread when https://github.com/asciidoctor/asciidoctor-pdf/issues/599 is fixed
+
+[cols="15,10,10,10,55",options="header"]
+|===
+|Key |Type |Required |Default |Description
+|wt |string |No |json |Defines the format of the response. The options are *json* or *xml*. If not specified, JSON will be returned by default.
+|===
+
+[[SchemaAPI-OUTPUT.6]]
+==== OUTPUT
+
+*Output Content*
+
+The output will simply be the schema version in use.
+
+[[SchemaAPI-EXAMPLES.6]]
+==== EXAMPLES
+
+Get the schema version
+
+[source,bash]
+----
+curl http://localhost:8983/solr/gettingstarted/schema/version?wt=json
+----
+
+[source,json]
+----
+{
+ "responseHeader":{
+ "status":0,
+ "QTime":2},
+ "version":1.5}
+----
+
+
+[[SchemaAPI-ListUniqueKey]]
+=== List UniqueKey
+
+`GET /_collection_/schema/uniquekey`
+
+[[SchemaAPI-INPUT.7]]
+==== INPUT
+
+*Path Parameters*
+
+// TODO: Change column width to %autowidth.spread when https://github.com/asciidoctor/asciidoctor-pdf/issues/599 is fixed
+
+[cols="30,70",options="header"]
+|===
+|Key |Description
+|collection |The collection (or core) name.
+|===
+
+*Query Parameters*
+
+The query parameters can be added to the API request after a '?'.
+
+// TODO: Change column width to %autowidth.spread when https://github.com/asciidoctor/asciidoctor-pdf/issues/599 is fixed
+
+[cols="15,10,10,10,55",options="header"]
+|===
+|Key |Type |Required |Default |Description
+|wt |string |No |json |Defines the format of the response. The options are *json* or *xml*. If not specified, JSON will be returned by default.
+|===
+
+[[SchemaAPI-OUTPUT.7]]
+==== OUTPUT
+
+*Output Content*
+
+The output will include simply the field name that is defined as the uniqueKey for the index.
+
+[[SchemaAPI-EXAMPLES.7]]
+==== EXAMPLES
+
+List the uniqueKey.
+
+[source,bash]
+----
+curl http://localhost:8983/solr/gettingstarted/schema/uniquekey?wt=json
+----
+
+[source,json]
+----
+{
+ "responseHeader":{
+ "status":0,
+ "QTime":2},
+ "uniqueKey":"id"}
+----
+
+
+[[SchemaAPI-ShowGlobalSimilarity]]
+=== Show Global Similarity
+
+`GET /_collection_/schema/similarity`
+
+[[SchemaAPI-INPUT.8]]
+==== INPUT
+
+*Path Parameters*
+
+// TODO: Change column width to %autowidth.spread when https://github.com/asciidoctor/asciidoctor-pdf/issues/599 is fixed
+
+[cols="30,70",options="header"]
+|===
+|Key |Description
+|collection |The collection (or core) name.
+|===
+
+*Query Parameters*
+
+The query parameters can be added to the API request after a '?'.
+
+// TODO: Change column width to %autowidth.spread when https://github.com/asciidoctor/asciidoctor-pdf/issues/599 is fixed
+
+[cols="15,10,10,10,55",options="header"]
+|===
+|Key |Type |Required |Default |Description
+|wt |string |No |json |Defines the format of the response. The options are *json* or *xml*. If not specified, JSON will be returned by default.
+|===
+
+[[SchemaAPI-OUTPUT.8]]
+==== OUTPUT
+
+*Output Content*
+
+The output will include the class name of the global similarity defined (if any).
+
+[[SchemaAPI-EXAMPLES.8]]
+==== EXAMPLES
+
+Get the similarity implementation.
+
+[source,bash]
+----
+curl http://localhost:8983/solr/gettingstarted/schema/similarity?wt=json
+----
+
+[source,json]
+----
+{
+ "responseHeader":{
+ "status":0,
+ "QTime":1},
+ "similarity":{
+ "class":"org.apache.solr.search.similarities.DefaultSimilarityFactory"}}
+----
+
+
+[[SchemaAPI-GettheDefaultQueryOperator]]
+=== Get the Default Query Operator
+
+`GET /_collection_/schema/solrqueryparser/defaultoperator`
+
+[[SchemaAPI-INPUT.9]]
+==== INPUT
+
+*Path Parameters*
+
+// TODO: Change column width to %autowidth.spread when https://github.com/asciidoctor/asciidoctor-pdf/issues/599 is fixed
+
+[cols="30,70",options="header"]
+|===
+|Key |Description
+|collection |The collection (or core) name.
+|===
+
+*Query Parameters*
+
+The query parameters can be added to the API request after a '?'.
+
+// TODO: Change column width to %autowidth.spread when https://github.com/asciidoctor/asciidoctor-pdf/issues/599 is fixed
+
+[cols="15,10,10,10,55",options="header"]
+|===
+|Key |Type |Required |Default |Description
+|wt |string |No |json |Defines the format of the response. The options are *json* or *xml*. If not specified, JSON will be returned by default.
+|===
+
+[[SchemaAPI-OUTPUT.9]]
+==== OUTPUT
+
+*Output Content*
+
+The output will include simply the default operator if none is defined by the user.
+
+[[SchemaAPI-EXAMPLES.9]]
+==== EXAMPLES
+
+Get the default operator.
+
+[source,bash]
+----
+curl http://localhost:8983/solr/gettingstarted/schema/solrqueryparser/defaultoperator?wt=json
+----
+
+[source,json]
+----
+{
+ "responseHeader":{
+ "status":0,
+ "QTime":2},
+ "defaultOperator":"OR"}
+----
+
+
+[[SchemaAPI-ManageResourceData]]
+== Manage Resource Data
+
+The <<managed-resources.adoc#managed-resources,Managed Resources>> REST API provides a mechanism for any Solr plugin to expose resources that should support CRUD (Create, Read, Update, Delete) operations. Depending on what Field Types and Analyzers are configured in your Schema, additional `/schema/` REST API paths may exist. See the <<managed-resources.adoc#managed-resources,Managed Resources>> section for more information and examples.
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/c8c2aab8/solr/solr-ref-guide/src/schema-browser-screen.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/schema-browser-screen.adoc b/solr/solr-ref-guide/src/schema-browser-screen.adoc
new file mode 100644
index 0000000..58444d9
--- /dev/null
+++ b/solr/solr-ref-guide/src/schema-browser-screen.adoc
@@ -0,0 +1,21 @@
+= Schema Browser Screen
+:page-shortname: schema-browser-screen
+:page-permalink: schema-browser-screen.html
+
+The Schema Browser screen lets you review schema data in a browser window.
+
+If you have accessed this window from the Analysis screen, it will be opened to a specific field, dynamic field rule or field type. If there is nothing chosen, use the pull-down menu to choose the field or field type.
+
+.Schema Browser Screen
+image::images/schema-browser-screen/schema_browser_terms.png[image,height=400]
+
+The screen provides a great deal of useful information about each particular field and fieldtype in the Schema, and provides a quick UI for adding fields or fieldtypes using the <<schema-api.adoc#schema-api,Schema API>> (if enabled). In the example above, we have chosen the `cat` field. On the left side of the main view window, we see the field name, that it is copied to the `\_text_` (because of a copyField rule) and that it use the `strings` fieldtype. Click on one of those field or fieldtype names, and you can see the corresponding definitions.
+
+In the right part of the main view, we see the specific properties of how the `cat` field is defined – either explicitly or implicitly via its fieldtype, as well as how many documents have populated this field. Then we see the analyzer used for indexing and query processing. Click the icon to the left of either of those, and you'll see the definitions for the tokenizers and/or filters that are used. The output of these processes is the information you see when testing how content is handled for a particular field with the <<analysis-screen.adoc#analysis-screen,Analysis Screen>>.
+
+Under the analyzer information is a button to *Load Term Info*. Clicking that button will show the top _N_ terms that are in a sample shard for that field, as well as a histogram showing the number of terms with various frequencies. Click on a term, and you will be taken to the <<query-screen.adoc#query-screen,Query Screen>> to see the results of a query of that term in that field. If you want to always see the term information for a field, choose *Autoload* and it will always appear when there are terms for a field. A histogram shows the number of terms with a given frequency in the field.
+
+[IMPORTANT]
+====
+Term Information is loaded from single arbitrarily selected core from the collection, to provide a representative sample for the collection. Full <<faceting.adoc#faceting,Field Facet>> query results are needed to see precise term counts across the entire collection.
+====
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/c8c2aab8/solr/solr-ref-guide/src/schema-factory-definition-in-solrconfig.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/schema-factory-definition-in-solrconfig.adoc b/solr/solr-ref-guide/src/schema-factory-definition-in-solrconfig.adoc
new file mode 100644
index 0000000..400bc16
--- /dev/null
+++ b/solr/solr-ref-guide/src/schema-factory-definition-in-solrconfig.adoc
@@ -0,0 +1,81 @@
+= Schema Factory Definition in SolrConfig
+:page-shortname: schema-factory-definition-in-solrconfig
+:page-permalink: schema-factory-definition-in-solrconfig.html
+
+Solr's <<schema-api.adoc#schema-api,Schema API>> enables remote clients to access <<documents-fields-and-schema-design.adoc#documents-fields-and-schema-design,schema>> information, and make schema modifications, through a REST interface.
+
+Other features such as Solr's <<schemaless-mode.adoc#schemaless-mode,Schemaless Mode>> also work via schema modifications made programatically at run time.
+
+[IMPORTANT]
+====
+Using the Managed Schema is required to be able to use the Schema API to modify your schema. However, using Managed Schema does not by itself mean you are also using Solr in Schemaless Mode (or "schema guessing" mode).
+
+Schemaless mode requires enabling the Managed Schema if it is not already, but full schema guessing requires additional configuration as described in the section <<schemaless-mode.adoc#schemaless-mode,Schemaless Mode>>.
+====
+
+While the "read" features of the Schema API are supported for all schema types, support for making schema modifications programatically depends on the `<schemaFactory/>` in use.
+
+[[SchemaFactoryDefinitioninSolrConfig-SolrUsesManagedSchemabyDefault]]
+== Solr Uses Managed Schema by Default
+
+When a `<schemaFactory/>` is not explicitly declared in a `solrconfig.xml` file, Solr implicitly uses a `ManagedIndexSchemaFactory`, which is by default `"mutable"` and keeps schema information in a `managed-schema` file.
+
+[source,xml]
+----
+ <!-- An example of Solr's implicit default behavior if no
+ no schemaFactory is explicitly defined.
+ -->
+ <schemaFactory class="ManagedIndexSchemaFactory">
+ <bool name="mutable">true</bool>
+ <str name="managedSchemaResourceName">managed-schema</str>
+ </schemaFactory>
+----
+
+If you wish to explicitly configure `ManagedIndexSchemaFactory` the following options are available:
+
+* `mutable` - controls whether changes may be made to the Schema data. This must be set to *true* to allow edits to be made with the Schema API.
+* `managedSchemaResourceName` is an optional parameter that defaults to "managed-schema", and defines a new name for the schema file that can be anything other than "`schema.xml`".
+
+With the default configuration shown above, you can use the <<schema-api.adoc#schema-api,Schema API>> to modify the schema as much as you want, and then later change the value of `mutable` to *false* if you wish to "lock" the schema in place and prevent future changes.
+
+[[SchemaFactoryDefinitioninSolrConfig-Classicschema.xml]]
+== Classic `schema.xml`
+
+An alternative to using a managed schema is to explicitly configure a `ClassicIndexSchemaFactory`. `ClassicIndexSchemaFactory` requires the use of a `schema.xml` configuration file, and disallows any programatic changes to the Schema at run time. The `schema.xml` file must be edited manually and is only loaded only when the collection is loaded.
+
+[source,xml]
+----
+ <schemaFactory class="ClassicIndexSchemaFactory"/>
+----
+
+[[SchemaFactoryDefinitioninSolrConfig-Switchingfromschema.xmltoManagedSchema]]
+=== Switching from `schema.xml` to Managed Schema
+
+If you have an existing Solr collection that uses `ClassicIndexSchemaFactory`, and you wish to convert to use a managed schema, you can simply modify the `solrconfig.xml` to specify the use of the `ManagedIndexSchemaFactory`.
+
+Once Solr is restarted and it detects that a `schema.xml` file exists, but the `managedSchemaResourceName` file (ie: "`managed-schema`") does not exist, the existing `schema.xml` file will be renamed to `schema.xml.bak` and the contents are re-written to the managed schema file. If you look at the resulting file, you'll see this at the top of the page:
+
+[source,xml]
+----
+<!-- Solr managed schema - automatically generated - DO NOT EDIT -->
+----
+
+You are now free to use the <<schema-api.adoc#schema-api,Schema API>> as much as you want to make changes, and remove the `schema.xml.bak`.
+
+[[SchemaFactoryDefinitioninSolrConfig-SwitchingfromManagedSchematoManuallyEditedschema.xml]]
+=== Switching from Managed Schema to Manually Edited `schema.xml`
+
+If you have started Solr with managed schema enabled and you would like to switch to manually editing a `schema.xml` file, you should take the following steps:
+
+. Rename the `managed-schema` file to `schema.xml`.
+. Modify `solrconfig.xml` to replace the `schemaFactory` class.
+.. Remove any `ManagedIndexSchemaFactory` definition if it exists.
+.. Add a `ClassicIndexSchemaFactory` definition as shown above
+. Reload the core(s).
+
+If you are using SolrCloud, you may need to modify the files via ZooKeeper. The `bin/solr` script provides an easy way to download the files from ZooKeeper and upload them back after edits. See the section <<solr-control-script-reference.adoc#SolrControlScriptReference-ZooKeeperOperations,ZooKeeper Operations>> for more information.
+
+[TIP]
+====
+To have full control over your `schema.xml` file, you may also want to disable schema guessing, which allows unknown fields to be added to the schema during indexing. The properties that enable this feature are discussed in the section <<schemaless-mode.adoc#schemaless-mode,Schemaless Mode>>.
+====
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/c8c2aab8/solr/solr-ref-guide/src/schemaless-mode.adoc
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/schemaless-mode.adoc b/solr/solr-ref-guide/src/schemaless-mode.adoc
new file mode 100644
index 0000000..992beac
--- /dev/null
+++ b/solr/solr-ref-guide/src/schemaless-mode.adoc
@@ -0,0 +1,268 @@
+= Schemaless Mode
+:page-shortname: schemaless-mode
+:page-permalink: schemaless-mode.html
+
+Schemaless Mode is a set of Solr features that, when used together, allow users to rapidly construct an effective schema by simply indexing sample data, without having to manually edit the schema.
+
+These Solr features, all controlled via `solrconfig.xml`, are:
+
+. Managed schema: Schema modifications are made at runtime through Solr APIs, which requires the use of `schemaFactory` that supports these changes - see <<schema-factory-definition-in-solrconfig.adoc#schema-factory-definition-in-solrconfig,Schema Factory Definition in SolrConfig>> for more details.
+. Field value class guessing: Previously unseen fields are run through a cascading set of value-based parsers, which guess the Java class of field values - parsers for Boolean, Integer, Long, Float, Double, and Date are currently available.
+. Automatic schema field addition, based on field value class(es): Previously unseen fields are added to the schema, based on field value Java classes, which are mapped to schema field types - see <<solr-field-types.adoc#solr-field-types,Solr Field Types>>.
+
+[[SchemalessMode-UsingtheSchemalessExample]]
+== Using the Schemaless Example
+
+The three features of schemaless mode are pre-configured in the `data_driven_schema_configs` <<config-sets.adoc#config-sets,config set>> in the Solr distribution. To start an example instance of Solr using these configs, run the following command:
+
+[source,bash]
+----
+bin/solr start -e schemaless
+----
+
+This will launch a Solr server, and automatically create a collection (named "```gettingstarted```") that contains only three fields in the initial schema: `id`, `\_version_`, and `\_text_`.
+
+You can use the `/schema/fields` <<schema-api.adoc#schema-api,Schema API>> to confirm this: `curl \http://localhost:8983/solr/gettingstarted/schema/fields` will output:
+
+[source,json]
+----
+{
+ "responseHeader":{
+ "status":0,
+ "QTime":1},
+ "fields":[{
+ "name":"_text_",
+ "type":"text_general",
+ "multiValued":true,
+ "indexed":true,
+ "stored":false},
+ {
+ "name":"_version_",
+ "type":"long",
+ "indexed":true,
+ "stored":true},
+ {
+ "name":"id",
+ "type":"string",
+ "multiValued":false,
+ "indexed":true,
+ "required":true,
+ "stored":true,
+ "uniqueKey":true}]}
+----
+
+[TIP]
+====
+Because the `data_driven_schema_configs` config set includes a `copyField` directive that causes all content to be indexed in a predefined "catch-all" `\_text_` field, to enable single-field search that includes all fields' content, the index will be larger than it would be without the `copyField`. When you nail down your schema, consider removing the `\_text_` field and the corresponding `copyField` directive if you don't need it.
+====
+
+[[SchemalessMode-ConfiguringSchemalessMode]]
+== Configuring Schemaless Mode
+
+As described above, there are three configuration elements that need to be in place to use Solr in schemaless mode. In the `data_driven_schema_configs` config set included with Solr these are already configured. If, however, you would like to implement schemaless on your own, you should make the following changes.
+
+[[SchemalessMode-EnableManagedSchema]]
+=== Enable Managed Schema
+
+As described in the section <<schema-factory-definition-in-solrconfig.adoc#schema-factory-definition-in-solrconfig,Schema Factory Definition in SolrConfig>>, Managed Schema support is enabled by default, unless your configuration specifies that `ClassicIndexSchemaFactory` should be used.
+
+You can configure the `ManagedIndexSchemaFactory` (and control the resource file used, or disable future modifications) by adding an explicit `<schemaFactory/>` like the one below, please see <<schema-factory-definition-in-solrconfig.adoc#schema-factory-definition-in-solrconfig,Schema Factory Definition in SolrConfig>> for more details on the options available.
+
+[source,xml]
+----
+<schemaFactory class="ManagedIndexSchemaFactory">
+ <bool name="mutable">true</bool>
+ <str name="managedSchemaResourceName">managed-schema</str>
+</schemaFactory>
+----
+
+[[SchemalessMode-DefineanUpdateRequestProcessorChain]]
+=== Define an UpdateRequestProcessorChain
+
+The UpdateRequestProcessorChain allows Solr to guess field types, and you can define the default field type classes to use. To start, you should define it as follows (see the javadoc links below for update processor factory documentation):
+
+[source,xml]
+----
+<updateRequestProcessorChain name="add-unknown-fields-to-the-schema">
+ <!-- UUIDUpdateProcessorFactory will generate an id if none is present in the incoming document -->
+ <processor class="solr.UUIDUpdateProcessorFactory" />
+ <processor class="solr.RemoveBlankFieldUpdateProcessorFactory"/>
+ <processor class="solr.FieldNameMutatingUpdateProcessorFactory">
+ <str name="pattern">[^\w-\.]</str>
+ <str name="replacement">_</str>
+ </processor>
+ <processor class="solr.ParseBooleanFieldUpdateProcessorFactory"/>
+ <processor class="solr.ParseLongFieldUpdateProcessorFactory"/>
+ <processor class="solr.ParseDoubleFieldUpdateProcessorFactory"/>
+ <processor class="solr.ParseDateFieldUpdateProcessorFactory">
+ <arr name="format">
+ <str>yyyy-MM-dd'T'HH:mm:ss.SSSZ</str>
+ <str>yyyy-MM-dd'T'HH:mm:ss,SSSZ</str>
+ <str>yyyy-MM-dd'T'HH:mm:ss.SSS</str>
+ <str>yyyy-MM-dd'T'HH:mm:ss,SSS</str>
+ <str>yyyy-MM-dd'T'HH:mm:ssZ</str>
+ <str>yyyy-MM-dd'T'HH:mm:ss</str>
+ <str>yyyy-MM-dd'T'HH:mmZ</str>
+ <str>yyyy-MM-dd'T'HH:mm</str>
+ <str>yyyy-MM-dd HH:mm:ss.SSSZ</str>
+ <str>yyyy-MM-dd HH:mm:ss,SSSZ</str>
+ <str>yyyy-MM-dd HH:mm:ss.SSS</str>
+ <str>yyyy-MM-dd HH:mm:ss,SSS</str>
+ <str>yyyy-MM-dd HH:mm:ssZ</str>
+ <str>yyyy-MM-dd HH:mm:ss</str>
+ <str>yyyy-MM-dd HH:mmZ</str>
+ <str>yyyy-MM-dd HH:mm</str>
+ <str>yyyy-MM-dd</str>
+ </arr>
+ </processor>
+ <processor class="solr.AddSchemaFieldsUpdateProcessorFactory">
+ <str name="defaultFieldType">strings</str>
+ <lst name="typeMapping">
+ <str name="valueClass">java.lang.Boolean</str>
+ <str name="fieldType">booleans</str>
+ </lst>
+ <lst name="typeMapping">
+ <str name="valueClass">java.util.Date</str>
+ <str name="fieldType">tdates</str>
+ </lst>
+ <lst name="typeMapping">
+ <str name="valueClass">java.lang.Long</str>
+ <str name="valueClass">java.lang.Integer</str>
+ <str name="fieldType">tlongs</str>
+ </lst>
+ <lst name="typeMapping">
+ <str name="valueClass">java.lang.Number</str>
+ <str name="fieldType">tdoubles</str>
+ </lst>
+ </processor>
+ <processor class="solr.LogUpdateProcessorFactory"/>
+ <processor class="solr.DistributedUpdateProcessorFactory"/>
+ <processor class="solr.RunUpdateProcessorFactory"/>
+</updateRequestProcessorChain>
+----
+
+Javadocs for update processor factories mentioned above:
+
+* {solr-javadocs}/solr-core/org/apache/solr/update/processor/UUIDUpdateProcessorFactory.html[UUIDUpdateProcessorFactory]
+* {solr-javadocs}/solr-core/org/apache/solr/update/processor/RemoveBlankFieldUpdateProcessorFactory.html[RemoveBlankFieldUpdateProcessorFactory]
+* {solr-javadocs}/solr-core/org/apache/solr/update/processor/FieldNameMutatingUpdateProcessorFactory.html[FieldNameMutatingUpdateProcessorFactory]
+* {solr-javadocs}/solr-core/org/apache/solr/update/processor/ParseBooleanFieldUpdateProcessorFactory.html[ParseBooleanFieldUpdateProcessorFactory]
+* {solr-javadocs}/solr-core/org/apache/solr/update/processor/ParseLongFieldUpdateProcessorFactory.html[ParseLongFieldUpdateProcessorFactory]
+* {solr-javadocs}/solr-core/org/apache/solr/update/processor/ParseDoubleFieldUpdateProcessorFactory.html[ParseDoubleFieldUpdateProcessorFactory]
+* {solr-javadocs}/solr-core/org/apache/solr/update/processor/ParseDateFieldUpdateProcessorFactory.html[ParseDateFieldUpdateProcessorFactory]
+* {solr-javadocs}/solr-core/org/apache/solr/update/processor/AddSchemaFieldsUpdateProcessorFactory.html[AddSchemaFieldsUpdateProcessorFactory]
+
+[[SchemalessMode-MaketheUpdateRequestProcessorChaintheDefaultfortheUpdateRequestHandler]]
+=== Make the UpdateRequestProcessorChain the Default for the UpdateRequestHandler
+
+Once the UpdateRequestProcessorChain has been defined, you must instruct your UpdateRequestHandlers to use it when working with index updates (i.e., adding, removing, replacing documents). Here is an example using <<initparams-in-solrconfig.adoc#initparams-in-solrconfig,InitParams>> to set the defaults on all `/update` request handlers:
+
+[source,xml]
+----
+<initParams path="/update/**">
+ <lst name="defaults">
+ <str name="update.chain">add-unknown-fields-to-the-schema</str>
+ </lst>
+</initParams>
+----
+
+[IMPORTANT]
+====
+After each of these changes have been made, Solr should be restarted (or, you can reload the cores to load the new `solrconfig.xml` definitions).
+====
+
+[[SchemalessMode-ExamplesofIndexedDocuments]]
+== Examples of Indexed Documents
+
+Once the schemaless mode has been enabled (whether you configured it manually or are using `data_driven_schema_configs` ), documents that include fields that are not defined in your schema should be added to the index, and the new fields added to the schema.
+
+For example, adding a CSV document will cause its fields that are not in the schema to be added, with fieldTypes based on values:
+
+[source,bash]
+----
+curl "http://localhost:8983/solr/gettingstarted/update?commit=true" -H "Content-type:application/csv" -d '
+id,Artist,Album,Released,Rating,FromDistributor,Sold
+44C,Old Shews,Mead for Walking,1988-08-13,0.01,14,0'
+----
+
+Output indicating success:
+
+[source,xml]
+----
+<response>
+ <lst name="responseHeader"><int name="status">0</int><int name="QTime">106</int></lst>
+</response>
+----
+
+The fields now in the schema (output from `curl \http://localhost:8983/solr/gettingstarted/schema/fields` ):
+
+[source,json]
+----
+{
+ "responseHeader":{
+ "status":0,
+ "QTime":1},
+ "fields":[{
+ "name":"Album",
+ "type":"strings"}, // Field value guessed as String -> strings fieldType
+ {
+ "name":"Artist",
+ "type":"strings"}, // Field value guessed as String -> strings fieldType
+ {
+ "name":"FromDistributor",
+ "type":"tlongs"}, // Field value guessed as Long -> tlongs fieldType
+ {
+ "name":"Rating",
+ "type":"tdoubles"}, // Field value guessed as Double -> tdoubles fieldType
+ {
+ "name":"Released",
+ "type":"tdates"}, // Field value guessed as Date -> tdates fieldType
+ {
+ "name":"Sold",
+ "type":"tlongs"}, // Field value guessed as Long -> tlongs fieldType
+ {
+ "name":"_text_",
+...
+ },
+ {
+ "name":"_version_",
+...
+ },
+ {
+ "name":"id",
+...
+ }]}
+----
+
+.You Can Still Be Explicit
+[TIP]
+====
+Even if you want to use schemaless mode for most fields, you can still use the <<schema-api.adoc#schema-api,Schema API>> to pre-emptively create some fields, with explicit types, before you index documents that use them.
+
+Internally, the Schema API and the Schemaless Update Processors both use the same <<schema-factory-definition-in-solrconfig.adoc#schema-factory-definition-in-solrconfig,Managed Schema>> functionality.
+====
+
+Once a field has been added to the schema, its field type is fixed. As a consequence, adding documents with field value(s) that conflict with the previously guessed field type will fail. For example, after adding the above document, the "```Sold```" field has the fieldType `tlongs`, but the document below has a non-integral decimal value in this field:
+
+[source,bash]
+----
+curl "http://localhost:8983/solr/gettingstarted/update?commit=true" -H "Content-type:application/csv" -d '
+id,Description,Sold
+19F,Cassettes by the pound,4.93'
+----
+
+This document will fail, as shown in this output:
+
+[source,xml]
+----
+<response>
+ <lst name="responseHeader">
+ <int name="status">400</int>
+ <int name="QTime">7</int>
+ </lst>
+ <lst name="error">
+ <str name="msg">ERROR: [doc=19F] Error adding field 'Sold'='4.93' msg=For input string: "4.93"</str>
+ <int name="code">400</int>
+ </lst>
+</response>
+----
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/c8c2aab8/solr/solr-ref-guide/src/search.json
----------------------------------------------------------------------
diff --git a/solr/solr-ref-guide/src/search.json b/solr/solr-ref-guide/src/search.json
new file mode 100755
index 0000000..186ed77
--- /dev/null
+++ b/solr/solr-ref-guide/src/search.json
@@ -0,0 +1,21 @@
+---
+title: search
+layout: none
+search: exclude
+---
+
+[
+{% for page in site.pages %}
+{% unless page.search == "exclude" %}
+{
+"title": "{{ page.title | escape }}",
+"tags": "{{ page.tags }}",
+"keywords": "{{page.keywords}}",
+"url": "{{ page.url | remove: "/"}}",
+"summary": "{{page.summary | strip }}"
+}
+{% unless forloop.last %},{% endunless %}
+{% endunless %}
+{% endfor %}
+
+]