Some interesting features of Sitecore 7

I was just reading the Sitecore 7 preview by MVP Dan Solovay, and I think these are very interesting new features that I look forward to being able to use:

  • Datasources finally support GUIDs, which means that renderings won’t break when items are moved. This is wired into the LinkManager, which means that you will get a warning if you delete an item referenced in a datasource field.
  • Datasources can also be built on search queries. I’d like to see more details on this one, but it certainly feels as a step in the right direction.
  • Search providers are now a pluggable component, with support for enterprise-grade Solr in addition to Lucene, and with support for RESTful-based ElasticSearch on the way. Tim Ward stressed that while Lucene is an acceptable option for normal (fewer than 100 million documents) implementations, Solr offers compelling scalability features (such as support for multiple servers and auto sharding) and can handle billions of documents.
  • All configuration settings for Lucene are now exposed through Sitecore configuration. This gives the developer a number of new knobs to turn in optimizing search performance.
  • LinqToSitecore has been updated from LinqToBuckets by providing IQueryable interfaces to Lucene and Solr. Dan highlights the significance of this explaining that while IEnumerable simply provides an enumeration of items, forcing you to do filter logic in memory (clearly not scalable if you are dealing with large number of objects), an IQueryable implementation builds a query that is executed against an index. Dan also brings up an example, to better explain this: “for instance, suppose you wanted to write a query for all product items that have a price under $10, and let’s say you had a very large number of products. An IEnumerable query would force you to iterate over all of them to select the qualifying items, whereas IQueryable pushes this work to the index.
  • You can reindex a small part of a content tree and you can configure an index to auto-swap, so that a new one is built in a temporary location so that a rebuild does not impact site functionality.
  • HTML caching can now be triggered by an index rebuild (“Clear on Index Update”). Again Dan clarifies the usefulness of this with an example: “This is helpful if your rendering uses index values, in the following scenario: You publish a change, the HTML cache is purged by the publish, but the index has not yet been updated. Bam, you are stuck with a stale value in cache until the next publish. This setting prevents that.
  • Search indexing and retrieval performance is vastly improved. Tim Ward cited that rebuilding an index with 10 million items on Sitecore 6.6 took 27 hours, and this was reduced to 98 minutes on the same equipment with Sitecore 7. Simple retrieval searches time was slashed from 3.9 seconds to 0.3 seconds, and complex searches (sort, date, and wildcard) that produce .Net exceptions on Sitecore 6.6 now work and take the same 0.3 seconds as simple searches.
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s