Searches

You can create traditional, free-text search scenarios and data-centric queries involving exact matching using filters. Optimizely Search & Navigation also supports data aggregation using facets.

📘

Note

When querying for objects inheriting IContent, use the GetContentResult extensions.

You search and query using an instance of the IClient interface. These extension methods offer 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 with 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 occur over indexed properties, including nested properties. You can select 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 Optimizely Search & Navigation solution, and may result in service unavailability. Also, searching with wildcard as prefix is not supported from version 15 of the client API. See Breaking changes for Find 15.

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

Recommendations

• Do not search with a wildcard asterisk (*). For example, avoid this syntax: query.For("*", x => x.query = "*");
• Never use prefix wildcards. If needed use an approach where you index the field value inverted and use suffix wildcards on an inverted query.
• Avoid wildcards on terms with less than 3 characters and more than 16 characters.
• Avoid wildcards on all or many fields.
• Avoid wildcards on large fields such as SearchText.
• If you spawn one wildcard query for each term, limit the number of wildcard queries.

Filter

The service and client API also support filtering. When applied to a free text query, filtering restricts search results to those that match 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 is programmed to ignore when indexing entries and retrieving search results.

Optimizely Search & Navigation, by default, indexes everything and does not apply stop words at the index level because their use negatively impacts precision. For example, a query containing a stop word matches any document and phrases it should not. Indexing everything supports exact phrase matches, even if a phrase has 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 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 Optimizely Search & Navigation.