Introduction To Relaxed Node Types

What are relaxed node types?

A node type is a JCR concept that relates to the structure of the repository. Node types define what a node of that type may or must contain in terms of properties and child nodes. For instance a node type can be defined that stipulates that a property called 'expires' of type date is mandatory for that type of node. In other words node type definitions or CNDs are the equivalent of schema definitions in XML and table definitions in a RDBMS database.

It is possible to relax the structural requirements you put on a node by using wildcards in your node type definitions. For instance you can say that a node can have any number of properties of type boolean, that you can name those properties whatever you like, and that they can be either multi-valued or single-valued. In CND notation this would look like this:

- * (boolean)
- * (boolean) multiple

This then is what is referred to as relaxing the node type.

Why should I care?

In Bloomreach Experience Manager, whenever you create a new document type using the document type editor, a corresponding CND is generated that defines what the nodes that represent documents of that type in the repository should look like. Before Bloomreach Experience Manager release 7.6 the CND that was generated used strict typing. Corresponding property definitions were declared only on fields that were explicitly added. Adding a field called 'expires' of type date resulted in the CND having the following entry:

- expires (date) 

From Bloomreach Experience Manager 7.6 onwards this is no longer the case. All document types you create using the document type editor have a very simple corresponding CND. This is because the node type of that document type inherits from a node type that defines all possible combinations of properties that you might need for your custom type. Therefore this CND no longer needs to be customized. Nor changed when you change the document type for that matter. And this is where the real added value of relaxed types comes in.

Remember that previously when you changed a document type you had to walk through all the documents of that type that were in the repository to add/remove/change the fields that were added/removed/changed in the type definition. This is what happened when you clicked 'update all content'. This in itself could be a very heavy operation depending on the amount of documents of that type that were in the repository. But not only that. To make it possible to change a type a rather complicated operation was needed because an entirely new namespace had to be introduced and the document type had to be moved to that new namespace. This in turn made the upgrade process more complicated.

With the introduction of relaxed node types changing the document type is a lot less involved than it was before. CNDs do not need to be updated and so no new namespaces need to be introduced. Also there is no longer the need to traverse all the documents of a type in order to update their contents to reflect the new type. The 'update all content' button has therefore been removed. This means that removing a field from the document type does not result in that field being deleted from the corresponding documents any more. The field is still there, just not visible anymore to an editor editing that document.

The latter is actually something you should be aware of when editing a document type. Re-adding a previously removed field will result in that field again being visible in the editor. However adding a field of the same name as a previously deleted field without that field being of the same type as before will wreak havoc on the CMS. This is a scenario that is definitely not supported and you are on your own if you attempt to do this.

Note that the relaxation of types only refers to the document data itself, meta-data related to workflow, taxonomy, tagging, etc. that is stored along with the document are still strictly typed. 

If after changing the document type you want to clean up your documents, you are advised to write and run an updater script to do that.

When not to use relaxed types

There are situations in which you would prefer to use strict typing instead. For instance if your documents are to be accessed and managed by code that is not under your own control, then type safety is an issue you should consider. Strict typing allows you to enforce the correct usage of your repository in this scenario. However, if the code that uses the repository is entirely under your own control then using relaxed typing gives you far more flexibility. The important thing to remember is that with relaxed types the responsibility for maintaining the structure of the repository has been moved from the repository itself to the code that accesses the repository.

So strict typing is still an option if your use case requires it. However, you won't be able to use the document type editor to manage your types anymore, and you must fall back to managing them manually.