When working with Content Search and Solr in Sitecore, it’s quite common that a field needs to be managed in both Sitecore and Solr. It can for example be a computed field or a basic field where you want specific field processing etc. where you need to slightly change the Solr schema. Having the configuration for such scenario split in two places can be quite annoying.

I while ago, I wrote a small module that’ll let you put your Solr Managed Schema configuration as part of the standard Sitecore configuration. This gives a better overview and configuration that plays together, stays together.

The module adds a new <solrManagedSchema> section in the contentSearch/indexConfiguration-section. The content of this section is almost identical to what you’d put in the Solr schema. The only difference is that fields, field types, dynamic fields and copy-fields are grouped separately with a Sitecore “hint” attribute.

Let’s describe the benefits of this with an example. Let’s say you need a computed field returning a set decimal numbers, like a set of variant specs etc. You’d obviously need the computed field class itself, but you’d also need to do a type match (because list of floats are not within the default mapping) and you’d need to modify the schema to support fields with multiple floats. The configuration could end up something like this:

<?xml version="1.0" encoding="utf-8" ?>
<configuration xmlns:role="http://www.sitecore.net/xmlconfig/role/"
               xmlns:search="http://www.sitecore.net/xmlconfig/search/">
  <sitecore search:require="Solr">
    <contentSearch>
      <indexConfigurations>
        <defaultSolrIndexConfiguration>
          <fieldMap type="Sitecore.ContentSearch.SolrProvider.SolrFieldMap, Sitecore.ContentSearch.SolrProvider">
            <typeMatches hint="raw:AddTypeMatch">
              <typeMatch type="System.Single[]" typeName="floatCollection" fieldNameFormat="{0}_fm" multiValued="true" settingType="Sitecore.ContentSearch.SolrProvider.SolrSearchFieldConfiguration, Sitecore.ContentSearch.SolrProvider" />
              <typeMatch type="System.Collections.Generic.List`1[System.Single]" typeName="floatCollection" fieldNameFormat="{0}_fm" multiValued="true" settingType="Sitecore.ContentSearch.SolrProvider.SolrSearchFieldConfiguration, Sitecore.ContentSearch.SolrProvider" />
            </typeMatches>
          </fieldMap>

          <documentOptions>
            <fields hint="raw:AddComputedIndexField">
              <field fieldName="my_float_list_fm" returnType="floatCollection" type="My.FloatList.ComputedField, My.Assembly"/>
            </fields>
          </documentOptions>
        </defaultSolrIndexConfiguration>

        <solrManagedSchema>
          <dynamicFields hint="raw:AddDynamicField">
            <!-- This will go into the Solr Managed Schema -->
            <dynamicField name="*_fm" type="pfloats" indexed="true" stored="true"/>
          </dynamicFields>
        </solrManagedSchema>
      </indexConfigurations>
    </contentSearch>
  </sitecore>
</configuration>

As you can see above, most of it is just common Sitecore config, but the changes to the managed schema goes almost seamlessly with it.

The example above is perhaps the most common one. More real world scenarios have, at least for me, been adjusting the index and query filters for certain fields, adjusting field store options for large search fields etc.

There are more examples of how it works here and you can grab the entire module code here. It’s been tested with Sitecore 9.3 and should work well with previous 9.x versions. However, the ISchemaPopulateHelper interface is slightly different in older versions, but it’s a simple change.

It’s worth noting that the module also contains a DefaultWithDebugPopulateHelper provider. As the name implies, it doesn’t change the default implementation and it add logging of all commands sent to Solr for easy debugging.

A couple of months ago I heard some rumor that this might go into the product in the future. Maybe it’s already in Sitecore 10 – I haven’t checked.