= Schema API
:page-tocclass: right
// Licensed to the Apache Software Foundation (ASF) under one
// or more contributor license agreements.  See the NOTICE file
// distributed with this work for additional information
// regarding copyright ownership.  The ASF licenses this file
// to you under the Apache License, Version 2.0 (the
// "License"); you may not use this file except in compliance
// with the License.  You may obtain a copy of the License at
//
//   http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing,
// software distributed under the License is distributed on an
// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
// KIND, either express or implied.  See the License for the
// specific language governing permissions and limitations
// under the License.

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 reindexed if existing index data uses schema elements that you changed.

.Reindex after schema modifications!
[IMPORTANT]
====
If you modify your schema, you will likely need to reindex 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 reindex 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.

See the section <<reindexing.adoc#reindexing,Reindexing>> for more information about reindexing.
====

////
// Commented out section because this makes less sense with 2 API endpoints available.
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
----
////

////
// TODO this needs to probably go away with v2 APIs?

== Schema API Entry Points

* `/schema`: <<Retrieve the Entire Schema,retrieve>> the schema, or <<Modify the Schema,modify>> the schema to add, remove, or replace fields, dynamic fields, copy fields, or field types
* `/schema/fields`: <<List Fields,retrieve information>> about all defined fields or a specific named field
* `/schema/dynamicfields`: <<List Dynamic Fields,retrieve information>> about all dynamic field rules or a specific named dynamic rule
* `/schema/fieldtypes`: <<List Field Types,retrieve information>> about all field types or a specific field type
* `/schema/copyfields`: <<List Copy Fields,retrieve information>> about copy fields
* `/schema/name`: <<Show Schema Name,retrieve>> the schema name
* `/schema/version`: <<Show the Schema Version,retrieve>> the schema version
* `/schema/uniquekey`: <<List UniqueKey,retrieve>> the defined uniqueKey
* `/schema/similarity`: <<Show Global Similarity,retrieve>> the global similarity definition
////

== Modify the 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 in JSON format 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 reindexed if they used schema elements that you changed.

=== 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 "pdate", you would POST the following request:

[.dynamic-tabs]
--
[example.tab-pane#v1add]
====
[.tab-label]*V1 API*
[source,bash]
----
curl -X POST -H 'Content-type:application/json' --data-binary '{
  "add-field":{
     "name":"sell_by",
     "type":"pdate",
     "stored":true }
}' http://localhost:8983/solr/gettingstarted/schema
----
====

[example.tab-pane#v2add]
====
[.tab-label]*V2 API*
[source,bash]
----
curl -X POST -H 'Content-type:application/json' --data-binary '{
  "add-field":{
     "name":"sell_by",
     "type":"pdate",
     "stored":true }
}' http://localhost:8983/api/cores/gettingstarted/schema
----
====
--

=== 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:

[.dynamic-tabs]
--
[example.tab-pane#v1delete]
====
[.tab-label]*V1 API*
[source,bash]
----
curl -X POST -H 'Content-type:application/json' --data-binary '{
  "delete-field" : { "name":"sell_by" }
}' http://localhost:8983/solr/gettingstarted/schema
----
====

[example.tab-pane#v2delete]
====
[.tab-label]*V2 API*
[source,bash]
----
curl -X POST -H 'Content-type:application/json' --data-binary '{
  "delete-field" : { "name":"sell_by" }
}' http://localhost:8983/api/cores/gettingstarted/schema
----
====
--

=== 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:

[.dynamic-tabs]
--
[example.tab-pane#v1replace]
====
[.tab-label]*V1 API*
[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
----
====

[example.tab-pane#v2replace]
====
[.tab-label]*V2 API*
[source,bash]
----
curl -X POST -H 'Content-type:application/json' --data-binary '{
  "replace-field":{
     "name":"sell_by",
     "type":"date",
     "stored":false }
}' http://localhost:8983/api/cores/gettingstarted/schema
----
====
--

=== 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:

[.dynamic-tabs]
--
[example.tab-pane#v1add-dynamic]
====
[tab-label]*V1 API*
[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
----
====

[example.tab-pane#v2add-dynamic]
====
[tab-label]*V2 API*
[source,bash]
----
curl -X POST -H 'Content-type:application/json' --data-binary '{
  "add-dynamic-field":{
     "name":"*_s",
     "type":"string",
     "stored":true }
}' http://localhost:8983/api/cores/gettingstarted/schema
----
====
--

=== 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:

[.dynamic-tabs]
--
[example.tab-pane#v1delete-dynamic]
====
[.tab-label]*V1 API*
[source,bash]
----
curl -X POST -H 'Content-type:application/json' --data-binary '{
  "delete-dynamic-field":{ "name":"*_s" }
}' http://localhost:8983/solr/gettingstarted/schema
----
====

[example.tab-pane#v2delete-dynamic]
====
[.tab-label]*V2 API*
[source,bash]
----
curl -X POST -H 'Content-type:application/json' --data-binary '{
  "delete-dynamic-field":{ "name":"*_s" }
}' http://localhost:8983/api/cores/gettingstarted/schema
----
====
--

=== 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:

[.dynamic-tabs]
--
[example.tab-pane#v1replace-dynamic]
====
[.tab-label]*V1 API*
[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
----
====

[example.tab-pane#v2replace-dynamic]
====
[.tab-label]*V2 API*
[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
----
====
--

=== 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:

[.dynamic-tabs]
--
[example.tab-pane#v1-single-analyzer]
====
[tab-label]*V1 API with Single Analysis*
[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.
====

[example.tab-pane#v1-two-analyzers]
====
[tab-label]*V1 API with Two Analyzers*

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
----
====

[example.tab-pane#v2-two-analyzers]
====
[tab-label]*V2 API with Two Analyzers*

To define two analyzers with the V2 API, we just use a different endpoint:
[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/api/cores/gettingstarted/schema
----
====
--

=== 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:

[.dynamic-tabs]
--
[example.tab-pane#v1delete-type]
====
[tab-label]*V1 API*
[source,bash]
----
curl -X POST -H 'Content-type:application/json' --data-binary '{
  "delete-field-type":{ "name":"myNewTxtField" }
}' http://localhost:8983/solr/gettingstarted/schema
----
====

[example.tab-pane#v2delete-type]
====
[tab-label]*V2 API*
[source,bash]
----
curl -X POST -H 'Content-type:application/json' --data-binary '{
  "delete-field-type":{ "name":"myNewTxtField" }
}' http://localhost:8983/api/cores/gettingstarted/schema
----
====
--

=== 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:

[.dynamic-tabs]
--
[example.tab-pane#v1replace-type]
====
[tab-label]*V1 API*
[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
----
====

[example.tab-pane#v2replace-type]
====
[tab-label]*V2 API*
[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/api/cores/gettingstarted/schema
----
====
--

=== 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:

`source`::
The source field. This parameter is required.

`dest`::
A field or an array of fields to which the source field will be copied. This parameter is required.

`maxChars`::
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:

[.dynamic-tabs]
--
[example.tab-pane#v1add-copyfield]
====
[.tab-label]*V1 API*
[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
----
====

[example.tab-pane#v2add-copyfield]
====
[.tab-label]*V2 API*
[source,bash]
----
curl -X POST -H 'Content-type:application/json' --data-binary '{
  "add-copy-field":{
     "source":"shelf",
     "dest":[ "location", "catchall" ]}
}' http://localhost:8983/api/cores/gettingstarted/schema
----
====
--

=== 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:

[.dynamic-tabs]
--
[example.tab-pane#v1delete-copyfield]
====
[tab-label]*V1 API*
[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
----
====

[example.tab-pane#v2delete-copyfield]
====
[tab-label]*V1 API*
[source,bash]
----
curl -X POST -H 'Content-type:application/json' --data-binary '{
  "delete-copy-field":{ "source":"shelf", "dest":"location" }
}' http://localhost:8983/api/cores/gettingstarted/schema
----
====
--

=== 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
----

=== 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.

== 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 <<Modify the Schema>>.

=== Retrieve the Entire Schema

`GET /_collection_/schema`

==== Retrieve Schema Parameters

*Path Parameters*

`collection`::
The collection (or core) name.

*Query Parameters*

The query parameters should be added to the API request after '?'.

`wt`::
Defines the format of the response. The options are *json*, *xml* or *schema.xml*. If not specified, JSON will be returned by default.

==== Retrieve Schema Response

*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.

==== Retrieve Schema Examples

Get the entire schema in JSON.

[source,bash]
----
curl http://localhost:8983/solr/gettingstarted/schema
----

[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>
----

=== List Fields

`GET /_collection_/schema/fields`

`GET /_collection_/schema/fields/_fieldname_`

==== List Fields Parameters

*Path Parameters*

`collection`::
The collection (or core) name.

`fieldname`::
The specific fieldname (if limiting the request to a single field).

*Query Parameters*

The query parameters can be added to the API request after a '?'.

`wt`::
Defines the format of the response. The options are `json` or `xml`. If not specified, JSON will be returned by default.

`fl`::
Comma- or space-separated list of one or more fields to return. If not specified, all fields will be returned by default.

`includeDynamic`::
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`, the default, matching dynamic fields will not be returned.

`showDefaults`::
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`, the default, only explicitly specified field properties will be included.

==== List Fields Response

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.

==== List Fields Examples

Get a list of all fields.

[source,bash]
----
curl http://localhost:8983/solr/gettingstarted/schema/fields
----

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
    }
}
----

=== List Dynamic Fields

`GET /_collection_/schema/dynamicfields`

`GET /_collection_/schema/dynamicfields/_name_`

==== List Dynamic Field Parameters

*Path Parameters*

`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 '?'.

`wt`::
Defines the format of the response. The options are `json` or `xml`. If not specified, JSON will be returned by default.

`showDefaults`::
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`, the default, only explicitly specified field properties will be included.

==== List Dynamic Field Response

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.

==== List Dynamic Field Examples

Get a list of all dynamic field declarations:

[source,bash]
----
curl http://localhost:8983/solr/gettingstarted/schema/dynamicfields
----

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
    }
}
----

=== List Field Types

`GET /_collection_/schema/fieldtypes`

`GET /_collection_/schema/fieldtypes/_name_`

==== List Field Type Parameters

*Path Parameters*

`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 '?'.

`wt`::
Defines the format of the response. The options are `json` or `xml`. If not specified, JSON will be returned by default.

`showDefaults`::
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`, the default, only explicitly specified field properties will be included.

==== List Field Type Response

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.

==== List Field Type Examples

Get a list of all field types.

[source,bash]
----
curl http://localhost:8983/solr/gettingstarted/schema/fieldtypes
----

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.FloatPointField",
            "dynamicFields": [
                "*_fs",
                "*_f"
            ],
            "fields": [
                "price",
                "weight"
            ],
            "name": "float",
            "positionIncrementGap": "0",
        }]
}
----

=== List Copy Fields

`GET /_collection_/schema/copyfields`

==== List Copy Field Parameters

*Path Parameters*

`collection`::
The collection (or core) name.

*Query Parameters*

The query parameters can be added to the API request after a '?'.

`wt`::
Defines the format of the response. The options are `json` or `xml`. If not specified, JSON will be returned by default.

`source.fl`::
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`::
Comma- or space-separated list of one or more copyField destination 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.

==== List Copy Field Response

The output will include the `source` and `dest` (destination) 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>>.

==== List Copy Field Examples

Get a list of all copyFields.

[source,bash]
----
curl http://localhost:8983/solr/gettingstarted/schema/copyfields
----

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
    }
}
----

=== Show Schema Name

`GET /_collection_/schema/name`

==== Show Schema Parameters

*Path Parameters*

`collection`::
The collection (or core) name.

*Query Parameters*

The query parameters can be added to the API request after a '?'.

`wt`::
Defines the format of the response. The options are `json` or `xml`. If not specified, JSON will be returned by default.

==== Show Schema Response

The output will be simply the name given to the schema.

==== Show Schema Examples

Get the schema name.

[source,bash]
----
curl http://localhost:8983/solr/gettingstarted/schema/name
----

[source,json]
----
{
  "responseHeader":{
    "status":0,
    "QTime":1},
  "name":"example"}
----

=== Show the Schema Version

`GET /_collection_/schema/version`

==== Show Schema Version Parameters

*Path Parameters*

collection::
The collection (or core) name.

*Query Parameters*

The query parameters can be added to the API request after a '?'.

`wt`::
Defines the format of the response. The options are `json` or `xml`. If not specified, JSON will be returned by default.

==== Show Schema Version Response

The output will simply be the schema version in use.

==== Show Schema Version Example

Get the schema version:

[source,bash]
----
curl http://localhost:8983/solr/gettingstarted/schema/version
----

[source,json]
----
{
  "responseHeader":{
    "status":0,
    "QTime":2},
  "version":1.5}
----

=== List UniqueKey

`GET /_collection_/schema/uniquekey`

==== List UniqueKey Parameters

*Path Parameters*

|`collection`::
The collection (or core) name.


*Query Parameters*

The query parameters can be added to the API request after a '?'.

|`wt`::
Defines the format of the response. The options are `json` or `xml`. If not specified, JSON will be returned by default.

==== List UniqueKey Response

The output will include simply the field name that is defined as the uniqueKey for the index.

==== List UniqueKey Example

List the uniqueKey.

[source,bash]
----
curl http://localhost:8983/solr/gettingstarted/schema/uniquekey
----

[source,json]
----
{
  "responseHeader":{
    "status":0,
    "QTime":2},
  "uniqueKey":"id"}
----

=== Show Global Similarity

`GET /_collection_/schema/similarity`

==== Show Global Similarity Parameters

*Path Parameters*

`collection`::
The collection (or core) name.

*Query Parameters*

The query parameters can be added to the API request after a '?'.

`wt`::
Defines the format of the response. The options are `json` or `xml`. If not specified, JSON will be returned by default.

==== Show Global Similary Response

The output will include the class name of the global similarity defined (if any).

==== Show Global Similarity Example

Get the similarity implementation.

[source,bash]
----
curl http://localhost:8983/solr/gettingstarted/schema/similarity
----

[source,json]
----
{
  "responseHeader":{
    "status":0,
    "QTime":1},
  "similarity":{
    "class":"org.apache.solr.search.similarities.DefaultSimilarityFactory"}}
----

== 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.
