Seamlessly switch Lucene indexes to avoid search downtime during re-indexing

(For those of you who don’t already know, John West is the Sitecore person. He wrote the book on Sitecore development, and his blog in particular is a treasure trove of Sitecore knowledge. He’s also an all-around nice guy, which I suppose fits his role as a technological evangelist; he’s always lending a hand to someone.)

During our current Sitecore upgrade, I found this gem: using the Lucene subdirectory-switching feature, via Sitecore.ContentSearch.LuceneProvider.SwitchOnRebuildLuceneIndex , allows for zero downtime when re-indexing in a production environment. Note that due to the use of two indexes, it may be necessary to rebuild twice when implementing indexing changes.

Some brief musings on search

We’re currently in the middle of upgrading a major codebase from Sitecore 6.6 to Sitecore 7.2 (and from thence to 7.5 or directly to 8.x). This has prompted a lot of soul-searching–how did we get here? Are we alone in the universe? And after a cup of coffee, some search-related thoughts have begun to emerge as well…

Solr is an exciting prospect, for sure, and the ContentSearch namespace is definitely much improved over what it’s replaced. Any pluggable architecture for any data-layer component always gives me the warm fuzzies. It’s actually kind of hot, in a strictly nerdy, programmatic sense.

Using PredicateBuilder to put together detailed queries can be a breeze. Still, the API is a bit clunky (I am apparently not alone in feeling so) and documentation seems to be a bit scattered. It seems that with a more careful eye to design, or maybe adding a bit of syntactic sugar somehow, the need for ugliness like an anchoring true-or-false condition could have been avoided, and the resulting programming style more natural.

Another persistent gripe of mine is the lack of some unification for Sitecore Query and Lucene (and now Solr) searches. The beauty of Sitecore Query, of course, is the beauty of XPath–although it may be a somewhat twisted, hobbled version, the orc to XPath-proper’s elf–and that is a declarative syntax. That’s why it’s used in tons of places within Sitecore, for data sources and more, as well as in third-party libraries like the wonderful Glass Mapper, which we use. You can’t beat the simplicity of referring, in your complex model, to related objects using an easily composed attribute path.

The fact is, in at least some situations where Lucene/Solr are valid choices for performance reasons, the actual search could be shoehorned into an XPath-like syntax too. Food for thought? I’m currently investigating something based on this… more later.