Last updated
Last updated
You can modify the built-in indexes in the following ways:
- giving you control over exactly what data goes into them and how the fields are configured
Changing the field value types to change how values are stored in the index
Changing the IValueSetValidator
to change what goes into the index
Take control of the entire index creation pipeline to change the implementation
We can do all this by using the ConfigureNamedOptions
pattern.
We will start by creating a ConfigureExamineOptions class, that derives from IConfigureNamedOptions<LuceneDirectoryIndexOptions>
:
When using the ConfigureNamedOptions
pattern, we have to register this in a composer for it to configure our indexes, this can be done like this:
By default, Examine will store values into the Lucene index as "Full Text" fields, meaning the values will be indexed and analyzed for a textual search. However, if a field value is numerical, date/time, or another non-textual value type, you might want to change how the value is stored in the index. This will let you take advantage of some value type-specific search features such as numerical or date range.
The easiest way to modify how a field is configured is using the ConfigureNamedOptions
pattern like so:
This will ensure that the price
field in the index is treated as a double
type (if the price
field does not exist in the index, it is added).
An IValueSetValidator
is responsible for validating a ValueSet
to see if it should be included in the index. For example, by default the validation process for the ExternalIndex checks if a ValueSet
has a category type of either "media" or "content" (not member). If a ValueSet
was passed to the ExternalIndex and it did not pass this requirement it would be ignored.
The IValueSetValidator
is also responsible for filtering the data in the ValueSet
. For example, by default the validator for the MemberIndex will validate on all the default member properties, so an extra property "PhoneNumber", would not pass validation, and therefore not be included.
The IValueSetValidator
implementation for the built-in indexes, can be changed like this:
The following example will show how to create an index that will only include nodes based on the document type product.
To create this index we need five things:
An UmbracoExamineIndex
implementation that defines the index.
An IConfigureNamedOptions
implementation that configures the index fields and options.
An IValueSetBuilder
implementation that builds index value sets a piece of content.
An IndexPopulator
implementation that populates the index with the value sets for all applicable content.
An INotificationHandler
implementation that updates the index when content changes.
A composer that adds all these services to the runtime.
The index will only update its content when you manually trigger an index rebuild in the Examine dashboard. This is not always the desired behavior for a custom index.
To update your index when content changes, you can use notification handlers.
There is some documentation about this in the .
Take a look at our to see some examples of how to search the ExternalIndex.
In certain scenarios only published content should be added to the index. To achieve that, you will need to implement your own logic to filter out unpublished content. This can be somewhat tricky as the published state can vary throughout an entire structure of content nodes in the content tree. For inspiration on how to go about such filtering, you can look at the .
The following handler class does not automatically update the descendant items of the modified content nodes, such as removing descendants of deleted content. If changes to the parent content item can affect its children or descendant items in your setup, please refer to the . Such logic should be applied when both removing and reindexing content items of type product.
You can find further inspiration for implementing notification handlers (for example, for media updates) in the .
Learn how to build and customize the indexes that comes with your Umbraco website.