A previous blog post talked about using the magic
#datecompare# token in the Sitecore query builder to be able to use the Solr date range comparisons. Well, after we implemented, we had really bad performance problems at startup - the first run of that query would look up the application for a solid 5-7 minutes (or at least it hit some unknown timeout), then would work fine afterwards. Even though it fixes itself after a while, that initial application locking wasn’t going to work.
Turns out the solution is that you have to explicitly declare the field in your Solr config. For whatever unknown reason, when Sitecore tries to dynamically create this field in the Solr configuration at runtime, it freezes up and freezes up hard. By explicitly declaring it in the configuration, it bypasses the dynamic registration of the field and therefore fixes the performance issue.
So, you need to explicitly add the field that you’re comparing against in your configuration file like so:
<?xml version="1.0" encoding="utf-8" ?> <configuration xmlns:patch="http://www.sitecore.net/xmlconfig/"> <sitecore> <contentSearch> <indexConfigurations> <defaultSolrIndexConfiguration> <fieldMap type="Sitecore.ContentSearch.SolrProvider.SolrFieldMap, Sitecore.ContentSearch.SolrProvider"> <fieldNames hint="raw:AddFieldByFieldName"> <field fieldName="compare_date" returnType="datetime" format="yyyy-MM-dd'T'HH:mm:ss'Z'"/> </fieldNames> </fieldMap> </defaultSolrIndexConfiguration> </indexConfigurations> </contentSearch> </sitecore> </configuration>