Sorting and Ordering Results

Sorting with a Search Provider is a bit of an oxymoron in my opinion. Search engines use complex algorithms to determine the order of the results - normally referred to as relevance order. However with Sitecore 7 and the new ContentSearch namespace, the idea is that you can use this not only for search but for getting quick access to results. We would like to get to the point with the ContentSearch namespace where people are comfortable to treat the index like a datastore instead of something that helps build search pages.

Facets Explained

Urban Dictionary defines a facet as one of the flat surfaces of a precious stone. Yes, that didn't help me either. Wikipedia on the other hand defines a facet as flat faces on geometric shapes...ah jeez!

A common request we are seeing through our support channel is to add a facet that shows workflow states for items. This is a nice way to not have to switch over to the workbox to see which content is in which state. In fact we even added a dynamic quick action in the search results screen that allows you to propagate items through workflow. Let's start by defining what we need to do.

Now that I am a local/official Dane (I went through an initiation phase of eating an entire raw herring, liquorice ice cream and my sarcasm level increased by 3) and have finished my first stint of Danish language lessons, it is my duty - nay - honour to help solve the issue of search with languages that use accents i.e. ø æ.

Sitecore 7 introduced a few new Field Types for you to use. The main additions were all based around search and offering field types that would allow you to utilise the power of the new ContentSearch LINQ layer. If you have not already seen the documentation I would recommend checking out Chapter 5.1 in this guide here. We had a quick peek and realised there is a lot of explanation that has been left out.

In Sitecore 7 we have done a lot of work to abstract away the provider that is powering all the search and indexing that is being done within the system. By doing this we have also abstracted away a lot of the complexity that comes with a search provider. However when there is something you need to talk to the provider directly about then a sudden hack guilt-trip becomes apparent and you wonder if talking to the provider directly is a good idea or not. The answer is - it is not a matter of feeling good or bad about it but talking to the provider only when it is 100% necessary. The team has mentioned it many times that we limited our SOLR support to what was supported in Lucene.net e.g. not supporting Grouping in the LINQ layer because Lucene.net does not have the support. We did this on purpose so moving between providers should be as transparent as possible. However we do not stop you from talking to Lucene.net or SOLR directly. In this post, we wanted to show you one way of doing it which is clean and will not require you to shower to clean away the dirt.

Great! You have made the upgrade to Sitecore 7. Coming with this you would have instantly got nice search within the UI, your old searches will be running on a new version of Lucene and you can start indexing media files. The next natural step is to move any code that is using the existing API over to use the new LINQ based API. This blog post details a process that the development team recommends for getting the high-level features that you should think about to plan your project. This blog is a running blog i.e. we will add more and more details to this over time.