The Fields screen presents information about fields in the index. On the left side of the screen, the Data Fields table presents the following information about each field in the index:
|Field||The name of the field.|
|Type||The field type.|
|Indexed||Whether or not the field should be indexed.|
|Stored||Whether or not the field should be stored.|
If a field is selected, the right side of the screen will show the settings for that field.
The following parameters are possible for each field in the index.
|Field Type|| The field type setting controls how a field is analyzed. There are many options available, and more can be added by adding a new plugin. It is crucial to understand the underlying values for a field in order to most reasonably set its type. For full text fields, such as "title", "body", or "description", a text field type is generally the desired setting, so that individual words in the text are searchable. There are various text field types, most are langauge specific. However, when a text field value is to be taken literally as-is (exact match only, or for faceting), the "string" type is likely the right choice.
There are also types for numeric data, including double, float, integer, and long (and variants of each suitable for sorting: sdouble, sfloat, sint, and slong). The date field accepts dates in the form "1995-12-31T23:59:59.999Z", with the fractional seconds optional, and trailing "Z" mandatory. Field types are defined in Solr's schema.xml file.
Additional advanced text types are available for many more languages with the additional optional Basis Technology integration. See the section Multilingual Indexing and Search for more information on integrating Basis Technology's software. If a field type is changed, reindexing is strongly recommended.
|Indexed||An indexed field is searchable on the words (or exact value) as determined by the field type. Unindexed fields are useful to provide the search client with metadata for display. For example, URL may not be a valuable search term, but it is very valuable metadata to show users in their result list. For performance reasons, a best practice is to index as few fields as necessary to still give users a satisfactory search experience. If this flag is changed, re-indexing all documents is required.|
|Stored||A field can be stored, independently of indexing, and made available in the results sent to to a search client. Reindexing is not necessary when changing the stored field flag, though fields in documents will remain as they were when they were originally indexed until reindexed.|
|Multi-Valued||Enable this if this field could have multiple values, such as be in multiple categories. It is recommended to reindex all documents after changing this setting.|
|Omit Term Frequencies and Positions||Enable this if the number of times a term occurs in a document (term frequency) and the proximity of a term to other terms (position) should not be stored. This may be useful for fields that are indexed but not used for searching.|
|Field Default||This allows a default value to be entered if the field is empty on the document.|
|Short Field Boost||This relevancy boost compensates for less text in short documents which have less opportunities for text matches and may otherwise rank lower in results than they should. Use 'moderate' for typical text fields such as the abstract or body of an article. Use 'high' for very short fields like title or keywords. Use 'none' for non-text fields. It is strongly recommended that changes to the short field boost be followed by a full reindex.|
|Search by Default||This requires that all queries search this field when no field has been specified by the user's query.|
|Include in Results||Controls whether the stored field value is returned to the search client. A field must be stored to be included in results. This setting can be changed without reindexing, as it is used query-time only.|
|Highlight||Controls whether highlighted snippets of the stored field value are returned to the search client. A field must be stored to be highlighted. This setting can be changed without reindexing, as it is used at query time only.|
|Facet||Enables a field's terms (words for text types, or exact value for "string" type) to be returned to the search client. In the LucidWorks Enterprise search interface, faceted fields are displayed and made navigable to constrain the search results. A field must be indexed to be facetable. This setting can be changed without reindexing, as it is used at query time only.|
|Use in "Find Similar"||Controls whether this field is taken into consideration in find-similar/more-like-this computations. The field must be indexed for it to be used for find-similar. This setting can be changed without reindexing, as it is used at query time only.|
|Index for Spellchecking||This allows terms from this field to be used in creation of a spellchecking index that by default will be created at the time of indexing. All fields selected for use in spell checking are combined into a single "spell" checking field for use in search suggestions. If this setting is changed, it's recommended to recreate the spellcheck index as described in Spell Checking and Automatic Completion of User Queries.|
|Index for Auto-complete||This allows terms from this field to be used in creation of a auto-complete index that by default will be created at the time of indexing. All fields selected for use in auto-complete are combined into a single "autocomplete" field for use in search suggestions. If this setting is changed, it's recommended to recreate the auto-complete index as described in Spell Checking and Automatic Completion of User Queries.|
|Enable for Query Synonym Expansion||These settings are used only with the LucidWorks Enterprise query parser setting for query-time handling of both synonyms and stop words. See for more details.|
|Enable Query-time Stopword Handling||This will require LucidWorks Enterprise to apply the stop word list to queries that use this specific field. This does not enable stop words across the board, only to queries on this field (may be most useful for 'body' fields, for example).|
|Use for Deduplication||This will use content indexed in this field for determining duplicated content and removing it from a user's result list.|