Using Solr field name resolution

Abstract

Overview of how Sitecore automatically maps document (item) field names to Solr field names.

Solr as a search provider dictates conventions for indexing and searching documents. When Sitecore sends a document (item) to Solr for indexing, the item fields must map to Solr fields. An example of mapping is when the Sitecore Item Name field maps to the Solr _name field.

Unfortunately, it is not practical to manually match large numbers of Sitecore fields to Solr fields. However, you can use Solr dynamic fields to perform automatic mappings for Sitecore fields.

An example of automatic mapping is when Sitecore maps the Sitecore parsedcreatedby computed string field to the Solr parsedcreatedby_s dynamic string field, because parsedcreatedby is associated with the Sitecore string index field type that is mapped to the *_s field name format.

All mappings are specified in the Sitecore.ContentSearch.Solr.DefaultIndexConfiguration.config file.

Field name resolution during indexing

Consider, for example, a Sitecore field named amount. It holds numbers and is therefore a Sitecore number type field. If the Sitecore field is not manually mapped by name to an index field type, Sitecore automatically maps it by Sitecore field type to a Solr dynamic field, in the following order:

  1. Sitecore maps the Sitecore number type field to the Solr float type field in the AddFieldByFieldTypeName section:

    <fieldTypes hint="raw:AddFieldByFieldTypeName">
  <fieldType fieldTypeName="number" returnType="float" />
  ...
</fieldType>

  2. Sitecore maps the Solr float type field to the {0}_tf field name format in the AddTypeMatch section:

    <typeMatches hint="raw:AddTypeMatch">
  <typeMatch
    typeName="float"
    type="System.Single"
    fieldNameFormat="{0}_tf"
    settingType="Sitecore.ContentSearch.SolrProvider.SolrSearchFieldConfiguration,
      Sitecore.ContentSearch.SolrProvider"
  />
  ...
</typeMatches>

  3. Sitecore replaces the {0} part with the Sitecore amount field name to become the Solr amount_tf field name.

  4. Sitecore indexes the Sitecore number type field named amount as a Solr dynamic float type field named amount_tf.

Overriding mappings by field name

Sitecore can override the mappings in the AddFieldByFieldTypeName section for each field in the AddFieldByFieldName section. You can use this feature, for example, to index the Sitecore title field as a Solr text type field named title_t. Sitecore uses the Sitecore field name and not the field type to match the Solr field type:

<fieldTypes hint="raw:AddFieldByFieldName">
  <field fieldName="title" returnType="text" />
  ...
</fieldTypes>

Indexing computed fields

Sitecore maps Sitecore computed fields to Solr dynamic fields in the AddComputedIndexField and AddTypeMatch sections. For example, Sitecore maps the Sitecore calculateddimension computed field to the Solr stringCollection type field and indexes it as calculateddimension_sm:

<fields hint="raw:AddComputedIndexField">
  <field fieldName="calculateddimension" returnType="stringCollection">
  Sitecore.ContentSearch.ComputedFields.CalculatedDimension,Sitecore.ContentSearch
  </field>
  ...
</fields>

<typeMatches hint="raw:AddTypeMatch">
  <typeMatch
    typeName="stringCollection"
    type="System.Collections.Generic.List`1[System.String]"
    fieldNameFormat="{0}_sm"
    multiValued="true"
    settingType="Sitecore.ContentSearch.SolrProvider.SolrSearchFieldConfiguration,
      Sitecore.ContentSearch.SolrProvider"
  />
  ...
</typeMatches>

Field name resolution during searching

Sitecore resolves fields in an almost identical way for searching and indexing. However, there is a small difference because information about the field and value type is missing. For example, when searching for title:Casablanca, Sitecore resolves the title field type to a Solr field name format, in the following order:

  1. Sitecore locates the template containing the title field.

  2. Sitecore learns that the title field type is Single-Line Text.

  3. Sitecore maps the Sitecore single-line text field type to the Solr text field type in the AddFieldsByTypeName section:

    <fieldTypes hint="raw:AddFieldByFieldTypeName">
  <fieldType
    fieldTypeName="html|rich text|single-line text|multi-line text|text|memo|image|reference"
    returnType="text"
  />
  ...
</fieldTypes>

  4. Sitecore maps the Solr text field type to the Solr {0}_t field name format in the AddTypeMatch section:

    <typeMatches hint="raw:AddTypeMatch">
  <typeMatch
    typeName="text"
    type="System.String"
    fieldNameFormat="{0}_t"
    cultureFormat="_{1}"
    settingType="Sitecore.ContentSearch.SolrProvider.SolrSearchFieldConfiguration,
      Sitecore.ContentSearch.SolrProvider"
  />
</typeMatches>

  5. Sitecore replaces the {0} part with the Sitecore title field name to resolve the Solr title_t field name.

  6. Sitecore sends the search query to Solr:

    /select?q=title_t:Casablanca

Searching with LINQ

When Sitecore uses LINQ to run search requests with strongly typed properties, Sitecore uses the .NET runtime type of the property to resolve the Solr field name in the AddTypeMatch section:

var queryable = index.CreateSearchContext().GetQueryable< CustomSearchResultItem >();
var q = queryable.Where(i => i.Airport.Equals("search term")).ToList();

public class CustomSearchResultItem : SearchResultItem {
  [IndexField("Airport")]
  [DataMember]
  public virtual string Airport { get; set; }
}

However, in situations when Sitecore can map a field type name to multiple .NET runtime types in the AddTypeMatch section, Sitecore uses the template resolver to inquire Solr for the template and the field type.

For example, the Sitecore airport property is a System.String type that maps to both the string and text .NET runtime types in the AddTypeMatch section. This results in two field name formats ({0}_s and {0}_t) and two Solr dynamic field names (airport_s and airport_t):

<typeMatches hint="raw:AddTypeMatch">
  <typeMatch
    typeName="string"
    type="System.String"
    fieldNameFormat="{0}_s"
    settingType="Sitecore.ContentSearch.SolrProvider.SolrSearchFieldConfiguration, 
      Sitecore.ContentSearch.SolrProvider"
  />
  <typeMatch
    typeName="text"
    type="System.String"
    fieldNameFormat="{0}_t"
    cultureFormat="_{1}"
    settingType="Sitecore.ContentSearch.SolrProvider.SolrSearchFieldConfiguration, 
      Sitecore.ContentSearch.SolrProvider"
  />
  ...
</typeMatches>

Sitecore uses the template resolver to query Solr for the template and the field type, in the following order:

  1. Sitecore sends the resolver request to Solr, for example:

    /select?q=_name:(airport)&fq=_templatename:("Template+field")&fq=_indexname:(sitecore_master_index)&rows=10&version=2.2}

    Important

    If two templates both define the same field, for example the airport field, the template resolver returns two results in an undetermined order. Sitecore always chooses the first result, making the resolution inconsistent. This is especially a problem if airport is defined as a Single-Line Text field type in one template and a Droplist field type in another template.

  2. Solr returns the single-line text field type that Sitecore maps to the Solr text field type in the AddFieldByFieldTypeName section:

    <fieldTypes hint="raw:AddFieldByFieldTypeName">
  <fieldType
    fieldTypeName="html|rich text|single-line text|multi-line text|text|memo|image" 
    returnType="text"
  />
</fieldTypes>

  3. Sitecore maps the Solr text field type to the {0}_t field name format in the AddTypeMatch section:

    <typeMatches hint="raw:AddTypeMatch">
  <typeMatch
    typeName="text"
    type="System.String"
    fieldNameFormat="{0}_t"
    cultureFormat="_{1}"
    settingType="Sitecore.ContentSearch.SolrProvider.SolrSearchFieldConfiguration,
      Sitecore.ContentSearch.SolrProvider"
  />
</typeMatches>

  4. Sitecore replaces the {0} part with the Sitecore airport property name resolving it to the Solr airport_t field.

  5. Sitecore sends the final search query to Solr:

    /select?q=_airport_t:”search term”&fq=_indexname:(sitecore_master_index)

Ensuring that templates are correctly indexed

Sitecore Content Search is dependent on templates being indexed to deliver complete and satisfying search results based on correct field type resolutions. Examples of configurations that leaves the templates unindexed are:

  • The Root tag of the crawler, which does not include the /sitecore/templates sub-tree:

    <crawler
  type="Sitecore.ContentSearch.SitecoreItemCrawler,
    Sitecore.ContentSearch">
  <Database>master</Database>
  <Root>/sitecore/content</Root>
</crawler>

  • The index document options, which are configured to exclude the template field items:

    <exclude hint="list:AddExcludedTemplate">
  <TemplateField>{455A3E98-A627-4B40-8035-E683A0331AC7}</TemplateField>
</exclude>

If your configuration requires it, add the TemplateIndexName tag to ensure that the templates are indexed. The tag must point to an index whose crawler indexes all Template Field items under the /sitecore/templates root:

<index
  id="sitecore_master_index"
  type="Sitecore.ContentSearch.SolrProvider.SolrSearchIndex, 
    Sitecore.ContentSearch.SolrProvider">
  ...
  <TemplateIndexName>TEMPLATE INDEX NAME</TemplateIndexName>
</index>

With the TemplateIndexName specified, Sitecore Content Search is able to resolve Solr mappings correctly for Sitecore fields that are used in queries to Solr. Failure to index templates can result in failing search requests or empty search results.