Searches

You can create traditional, free-text search scenarios and data-centric queries involving exact matching using filters. 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.

📘

Note

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.