Introduction to Relaxed Node Types

Overview

This page explains the concept of relaxed node types in Bloomreach Content, their implementation, and when to use them.

What Are Relaxed Node Types?

In the Java Content Repository (JCR), a node type defines the structure of a node. Node types specify which properties and child nodes a node must or may contain. For example, you can define a node type that requires a mandatory property named expires of type date. Node type definitions, also known as Compact Node Definition (CND) files, are similar to XML schema definitions or table definitions in relational databases.

Relaxed node types allow you to use wildcards in your node type definitions to reduce structural constraints. For example, you can permit a node to have any number of boolean properties, with any property names, and allow them to be single- or multi-valued. In CND notation, this is represented as:

- * (boolean)
- * (boolean) multiple

Relaxing the node type means you are not enforcing strict property names or counts.

Why Use Relaxed Node Types?

When you create a new document type in Bloomreach Content using the document type editor, the system generates a CND that defines the structure of nodes for that document type. Before version 7.6, the generated CNDs were strictly typed. Only explicitly added fields were declared. For example, adding a date field named expires resulted in the following CND entry:

- expires (date) 

Starting with version 7.6, Bloomreach Content uses relaxed node types for all document types created with the document type editor. The generated CND is simplified because the document type inherits from a base node type that already defines all possible property combinations required for custom types. As a result, you no longer need to customize or update the CND when you change the document type.

Previously, changing a document type required updating all existing documents of that type in the repository to match the new structure. This process, triggered by the "update all content" action, could be resource-intensive, especially with large numbers of documents. Additionally, changing a type required introducing a new namespace and migrating the document type, which complicated upgrades.

With relaxed node types, you do not need to update CNDs or introduce new namespaces when changing document types. There is no need to traverse and update all documents of a type to reflect structural changes. As a result, the "update all content" button has been removed. Removing a field from a document type no longer deletes that field from existing documents; the field remains in the data but is no longer visible to editors.

Be aware that if you re-add a previously removed field, it becomes visible again in the editor. However, if you add a field with the same name as a previously deleted field but assign it a different type, this can cause issues in the CMS. This scenario is not supported.

Relaxed typing applies only to document data. Metadata related to workflow, taxonomy, tagging, and similar features remains strictly typed.

If you need to clean up documents after changing a document type, use an updater script.

When Not to Use Relaxed Types

Strict typing is preferable in scenarios where external code (not under your control) accesses and manages documents. Strict typing enforces repository structure and type safety. If you control all code that interacts with the repository, relaxed typing provides more flexibility, but you are responsible for maintaining repository structure in your code.

If your use case requires strict typing, you must manage node types manually. The document type editor does not support strict typing.