The field types for Azure Cognitive Search

Current version: 9.0

Within the Sitecore Azure Cognitive Search, you can define a data type for either a specific field or a Sitecore field type. This means you can control how the field is defined in the Azure Cognitive Search index. By default, Sitecore adds field type suffixes to the field names stored in the index. This ensures that there are no conflicts for fields defined in Sitecore that have the same name but have different field types. Fields with the same logical name but different EDM types are stored in different physical fields in the index.

When you configure field mapping, you must apply it at two different levels. You can map specific Sitecore fields or Sitecore field types to .Net types, and you can also map.Net types to EDM field types. The EDM field type is the data type the field is stored in within the Azure Cognitive Search index.

Mapping Sitecore fields types to .Net types

In the Sitecore.ContentSearch.Azure.DefaultIndexConfiguration.config file, you can see how to map Sitecore field types to .Net field types.

For example, you can map the Sitecore field type of rich text to the .Net type “System.String”:

RequestResponse
<fieldTypes hint="raw:AddFieldByFieldTypeName">
...
<fieldType fieldTypeName="rich text"  boost="1f" type="System.String" searchable="YES" retrievable="YES"  facetable="YES"  filterable="YES"  sortable="YES" settingType="Sitecore.ContentSearch.Azure.CloudSearchFieldConfiguration, Sitecore.ContentSearch.Azure" cloudAnalyzer="language" />
...
</fieldTypes>

You can also map specific fields to .Net types. This setup has a higher priority and will override the field type setup.

For example, you can map the field named “testfield1” to the .Net type "System.String":

RequestResponse
<fieldNames hint="raw:AddFieldByFieldName">
...
<field fieldName="testfield1"  cloudFieldName="testfield1" searchable="YES"  retrievable="YES" facetable="YES"  filterable="YES"  sortable="YES"  boost="1f" type="System.String"   settingType="Sitecore.ContentSearch.Azure.CloudSearchFieldConfiguration, Sitecore.ContentSearch.Azure" />
...
</fieldNames>

Mapping .Net types to EDM types

In the Sitecore.ContentSearch.Azure.DefaultIndexConfiguration.config file, you can see how to map .Net field types to an EDM field type.

For example, you can map fields with the .Net field type "System.Char" to the "Edm.String" field type:

RequestResponse
<cloudTypeMapper type="Sitecore.ContentSearch.Azure.Schema.CloudSearchTypeMapper, Sitecore.ContentSearch.Azure">
        ...
             <maps hint="raw:AddMap">
              <map type="System.Char” cloudType="Edm.String" />
             </maps>
        ...
</cloudTypeMapper>

Type suffixes for EDM types

Type suffixes are appended to original field names in the Azure Cognitive Search index. In the Sitecore.ContentSearch.Azure.DefaultIndexConfiguration.config file, you can see how to define the values of suffixes. Refer to the following table for the default values:

Original field name

Field type

Field name with suffix

field1

Edm.String

field1_s

field1

Collection(Edm.String)

field1_sm

field1

Edm.Boolean

field1_b

field1

Edm.Int32

field1_i

field1

Edm.Int64

field1_I

field1

Edm.Double

field1_d

field1

Edm.DateTimeOffset

field1_dt

How Sitecore Azure Cognitive Search stores data

For an item that has two fields with the same name but different types, see the following example of how Sitecore Azure Cognitive Search stores the data.

A template definition can contain two fields with the same name Field1, for example, but with different field types. In the following example they are: Single-Line Text and Integer.

From this template, you can create an item called Test1 and populate the two fields with different values.

In the index, you can see there are two fields with the same name, field1, however they contain different field types. These field types are defined by different suffixes: field1_l (the Edm.Int64 field type), and field1_s (the Edm.String field type). Using suffixes avoids conflicts when you have a duplicate field name that has different field types.

Do you have some feedback for us?

If you have suggestions for improving this article,