Dear Wiki user, You have subscribed to a wiki page or wiki category on "Solr Wiki" for change notification.
The following page has been changed by HossMan: http://wiki.apache.org/solr/SchemaXml ------------------------------------------------------------------------------ - The schema.xml file contains all of the details about which fields your documents can contain, and how those fields should be dealt with when adding documents to the index, or when querying those fields. A [http://svn.apache.org/repos/asf/incubator/solr/trunk/example/solrconf/schema.xml sample Solr schema.xml with detailed comments] can be found in the Source Repository. @@ -9, +8 @@ [[TableOfContents]] - == Data Types` == + == Data Types == - The `<types>` section allows you define a list of `<fieldtype>` you wish to use in your schema, along with the underlying Solr class that should be used for that type, as well as the default options you want for fields that use that type. + The `<types>` section allows you define a list of `<fieldtype>` declarations you wish to use in your schema, along with the underlying Solr class that should be used for that type, as well as the default options you want for fields that use that type. - Any subclass of [http://incubator.apache.org/solr/docs/api/org/apache/solr/schema/FieldType.html FieldType] may be used as a field type class. for some common numeric types (integer, float, etc...) there are multiple implimentations provided depending on your needs. + Any subclass of [http://incubator.apache.org/solr/docs/api/org/apache/solr/schema/FieldType.html FieldType] may be used as a field type class, using either it's full package name, or the "solr" alias if it is in the default Solr pacakge. For common numeric types (integer, float, etc...) there are multiple implimentations provided depending on your needs. Common options that field types can have are... @@ -23, +22 @@ * `stored=true|false` * `multiValued=true|false` * `omitNorms=true|false` + * `positionIncrementGap=N` `TextField`s can also support Analyzers with highly configurable [:AnalyzersTokenizersTokenFilters:Tokenizers and Token Filters]. + /!\ :TODO: /!\ do omitNorms and positionIncrementGap have any meaning for non !TextFields? == Fields == - == Misc == + + The `<fields>` section is where you list the individual `<field>` declarations you wish to use in your documents. Each `<field>` has a name that you will use to refrence it when adding documents or executing searches, and an associated type which identifies the name of the fieldtype you wish to use for this field. Individual fields can override the various options (indexed, stored, etc...) that it inherits from it's fieldtype. + + One of the powerful features of Lucene is that you don't have to pre-define every field when you first create your index. Even though Solr provides strong datatyping for fields, it still prserves that flexability using "Dynamic Fields". Using `<dynamicField>` declarations, you can create field rules that Solr will use to understand what datatype should be used whenever it is given a field name that is not explicitly defined, but matches a prefix or suffix used in a dynamicField. + + For example the following dynamic field declaration tells Solr that whenever it sees a field name ending in "_i" which is not an explicitly defined field, then it should dynamically create an integer field with that name... + + {{{ + <dynamicField name="*_i" type="integer" indexed="true" stored="true"/> + }}} + + + == Miscellaneous Settings == + + In addition to the `<fieldtypes>` and `<fields>` sections o the schema, there are several other declarations that can appear in your schema.... + === The Unique Key Field === + + The `<uniqueKey>` declaration can be used to inform Solr that there is a field in your index which should be unique for all documents. If a document is added that contains the same value for this field as an existing document, the old document will be deleted. + + It is not mandatory for a schema to have a uniqueKey field. + === The Default Search Field === + + The `<defaultSearchField>` Is used by Solr when parsing queries to identify which field name should be searched in queries where an explicit field name has not been used. + === Copy Fields === - /!\ :TODO: /!\ CNET doesn't seem to ever have written detailed schema docs, we need some + Any number of `<copyField>` declarations can be included in your schema, to instruct Solr that you want it to duplicate any data it sees in the "source" field of documents that are added to the index, in the "dest" field of that document. You are responsible for ensuring that the datatypes of the fields are compatable, but Solr will process the information in the "dest" field using the appropriate field type (and Analyzer if it's a !TextField). + This is provided as a convinient way to ensure that data is put into several fields, without needing to include the data in the update command multiple times. + + === Similarity === + + + A `<similarity>` declatation can be used to specify the subclass of Similarity that you want Solr to use when dealing with your index. If no Similarity class is specified, the Lucene DefaultSimilarity is used. +
