Sitecore Swamp

Sitecore Query

Sitecore Query is probably the most commonly used approach as its the standard way to query content. Sitecore-certified developers likely all know Sitecore query as a starting point. An easy way to help build up your queries correctly is to use the XPath builder in the Developer Center.

Unfortunately, Sitecore Query has performance issues depending on how you build your queries. Creating very specific queries has a performance hit because the query magic built into Sitecore has to do more checks on each item. A recommended practice when using Sitecore Query is to make your queries as generic as you can and use .NET to loop over the results and filter them further.

Let’s consider the following type of query and how it can be adjusted. Say you want to retrieve all items at a specific path of a certain template type where each item has specific field values. A good approach would be to not include the check for the field values in the query, but filter the results using C#. So for example, let’s find all Employees under the About section and filter them with C# based on some field criteria. The example below makes a fairly generic Sitecore query and uses LINQ to filter the results:

The lines of code above will: (1) get all immediate children of template “Employee” under the “about” item, and (2) will use LINQ to loop over each resulting Sitecore Item and will check if both the “First Name” and “Last Name” fields are not empty strings. The resulting IEnumerable<Item>now contains only Employee items with those fields filled in. The above code is fairly useless but it shows how you can use LINQ to filter your general result sets as opposed to writing a long Sitecore Query to be very specific.

One important thing to note is that a self-or-descendant selector (i.e. //*) is not recommended. This performs a recursive query down all subitems and will cause performance issues. It is recommended that both front-end code and template field queries not use self-or-descendant as they can slow down the front-end of the site or even the content editor itself.

It’s also important to note that special characters in queries need to be escaped with a hash, for example, a hyphen in a query will break the parser and needs to be handled by being wrapped in #.

This query will not work:

This one will:

Fast Query

Fast Query is very similar to Sitecore Query but it is more restrictive on what you can query with, however is performs faster than a reulgar Sitecore query. Fast Query is recommended to retrieve many more items than a Sitecore query. The prefix for a fast query is “query:fast:”. Fast queries are actually translated directly into SQL statements and executed on the database, so there are limitations. I recommend you read the Fast Query doc on the SDN.

Lucene Search

My experience with querying Sitecore with Lucene is fairly new, but is the result of Alex Shyba’s work at Sitecore with Lucene. Alex has created a great toolkit called the Advanced Database Crawler to make it easier for developers to setup and query Lucene with some pretty simple C#. The best way to get started using Alex’s toolkit would be to watch his video series on sample search scenarios and configuration settings. In the future I will publish a summary of my findings with this new tool and the things I’ve learned while using it.

Determine How You Should Query Sitecore

Below is a table of recommended approaches to querying Sitecore based on the number of items in the result sets. Note that the web.configsetting Query.MaxItem affects the number of items that a Sitecore query can return. Say if you want to return 150 items from a Sitecore query (not recommended), you’d need to adjust the setting. The higher this number is, the more you can get back from your Sitecore queries which means the worse your app can perform because of these large queries.

var request = new RestRequest("ShoppingBasket") { Method = Method.POST, RequestFormat = DataFormat.Json};
request.AddBody(basketLineItem);
var response = _client.Execute(request);