Indexable
QName: f:indexable
Informs a node of how it should be indexed. Cloud CMS maintains multiple indexes
including a search index, a database index and special indexes for things like path-based retrieval.
By default, all n:node
instances have the f:indexable
feature applied to them. The default
behavior is for search to be enabled and for search-indexes to be updated synchronously upon a write.
Nodes that are indexed for search will take a little extra time on write (create or update) since the
underlying ElasticSearch indexing engine must take the JSON and index it. If your node has any attachments,
those attachments will have text extracted from them to fill out the index as well.
For performance reasons, you may wish to disable search indexing for some nodes. You can do this at either the
node instance or node definition level (in which case the optimization will work for all nodes of that type).
You can specify properties by path which you do not want to index in elastic search and therefore those properties will not impact
search results. This can be helpful in preventing unwanted search results for appearing in certain instances, as well as aiding in fixing
elastic search type conflicts.
In addition, for further performance reasons with large quantities of content, you may wish to apply custom database
collection indexing for your repository branches. This is beyond the scope and intention of thef:indexable
feature but is provided with per-branch index descriptions. Please see our documentation
on indexing for more details.
Configuration
<thead>
<tr>
<th>Property</th>
<th>Type</th>
<th>Default</th>
<th nowrap>Read-Only</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td>schedule</td>
<td>text</td>
<td></td>
<td></td>
<td>
Defines how the search-index should be updated - either
<code>SYNCHRONOUS</code> or <code>ASYNCHRONOUS</code>
</td>
</tr>
<tr>
<td>disableSearchIndex</td>
<td>boolean</td>
<td>false</td>
<td></td>
<td>
Whether to disable the indexing of the node and it's attachments for full-text search.
</td>
</tr>
<tr>
<td>excludePaths</td>
<td>array</td>
<td>[]</td>
<td></td>
<td>
Optional array of Java regular expression strings, which represent paths of properties to not index
in elastic search.
</td>
</tr>
</tbody>
Indexable Example
Here is an example of a type definition for an article. Full-text search is enabled and all search-indexes are to be
computed in the background (asynchronously). Asynchronous computation means that the index may not update right away.
You might commit 1000 nodes, for example, and then immediately search for them and not find them for several seconds.
If you require immediate search results, set the schedule to synchronous. The tradeoff is that synchronous search
index updates will cause your commit to take longer.
{
"title": "Article",
"type": "object",
"properties": {
"author": {
"type": "string"
},
"body": {
"type": "string"
}
},
"mandatoryFeatures": {
"f:indexable": {
"schedule": "ASYNCHRONOUS",
"disableSearchIndex": false
}
}
}
Exclude Paths Example
Suppose in our content model we have a number of properties which begin with "metadata_" that we do not wish for users to be able
to search on and find corresponding documents. We can exclude all such properties by adding "metadata_.*" to our indexable exclude paths.
{
"title": "Article",
"type": "object",
"properties": {
"author": {
"type": "string"
},
"metadata_foo": {
"type": "string"
},
"metadata_bar": {
"type": "string"
}
},
"mandatoryFeatures": {
"f:indexable": {
"excludePaths": [ "metadata_.*" ]
}
}
}
You can also exclude nested properties using /
separated property paths. In this example we exclude the nested baz
property from search indexing:
{
"title": "Deeply Nested",
"type": "object",
"properties": {
"foo": {
"type": "object",
"properties": {
"bar": {
"type": "object",
"properties": {
"baz": {
"type": "string"
},
"wiz": {
"type": "string
}
}
}
}
}
},
"mandatoryFeatures": {
"f:indexable": {
"excludePaths": [ "foo/bar/baz" ]
}
}
}