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 the f:indexable feature but is provided with per-branch index descriptions. Please see our documentation on indexing for more details.

Configuration

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" ]
        }
    }
}