Searching

Episerver Find excels in traditional, free-text search scenarios and data-centric queries involving exact matching using filters. Find also supports data aggregation using facets. This topic introduces search and filtering in Find.

Note: When querying for objects inheriting IContent, the GetContentResult extensions should be used. For information, see GetContentResult.

How it works

You search and query using an instance of the IClient interface. This, along with extension methods, offers a traditional, object-oriented API and convenient fluent API. Most documentation found here covers the fluent API.

Searches

You can execute a free-text search for objects of a specific type via the GetResult method, which returns:

An object with result items
The number of documents that match the search query
Facets
Information about execution time

var searchResult = client.Search<BlogPost>()
  .For("Beethoven")
  .GetResult();

int numberOfDocsMatchingTheSearch = searchResult.TotalMatching;
int executionTime = searchResult.ServerDuration;
FacetResults facets = searchResult.Facets;
IEnumerable<SearchResultItem<BlogPost>> hits = searchResult.Hits;

Each hit object contains the indexed object, its ID, highlights (if requested), and its score.

var searchResult = client.Search<BlogPost>()
  .For("Beethoven")
  .GetResult();

foreach (var hit in searchResult.Hits)
  {
    string id = hit.Id;
    BlogPost item = hit.Item;
    Highlights highlights = hit.Highlights;
    double? score = hit.Score;
  }

Unless specified, searches are performed over all indexed properties, including nested properties. You can specify which properties to search.

client.Search<BlogPost>()
  .For("Beethoven")
  .InFields(x => x.Title, 
            x => x.Tags,
            x => x.Author.Name);

Wildcard searches

A wildcard is a search technique where a search query includes, for example, an asterisk (*) to specify any number of unspecified characters.

Note: Excessive use of wildcard searches may seriously impact the performance of your Find solution, and may result in service unavailability.

Example: *work or *work*
Not only would these be performance heavy, they may also give irrelevant results and bad relevance.

Recommendations:

Do not search with a wildcard star (*). For example, avoid this syntax: query.For("*", x => x.query = "*");
Never use prefix or suffix wildcards or both.
Use at least 3 characters with wildcards.
Avoid wildcards on many or all fields.
Avoid wildcards on lengthy fields.

Filtering

The service and client API also supports filtering. If applied to a free text query, filtering restricts search results to those matching the filters.

client.Search<BlogPost>()
  .For("Beethoven")
  .Filter(x => x.Tags.Match("Music"));

If applied without a free text query, filters let you query for objects in an exact manner, similar to traditional database queries.

client.Search<BlogPost>()
  .Filter(x => x.Tags.Match("Music"));

Stop words

A “stop word” is a commonly used word that a search engine has been programmed to ignore when indexing entries, and when retrieving search results.

By default, Episerver Find indexes everything and does not apply stop words at the index level. This is because the use of stop words negatively impacts precision. For example, if a query contains a stop word, it matches any document, and matches phrases that it should not. Indexing everything supports exact phrase matches, even if a phrase contains a word that one might consider a stop word.

MoreLikeThis is a special case. Here, stop words are used when selecting terms from the source document, and the stop word is simply a part of that specific query.

If you still want to use stop words in a query, remove them from the query string before passing it to Episerver Find.

Do you find this information helpful? Yes No

Why wasn't this helpful? (check all that apply) Couldn't find what I was looking for Instructions confusing or unclear Instructions didn't work

Please tell us more! (optional)

We're doing our best to answer your questions in the documentation. If we have not, please explain what you are looking for.

If possible, provide your email address. We may contact you to fully understand your comments and update the documentation accordingly.

Email address (optional):

Last updated: Mar 27, 2019