Data source definition

This page describes data source definition of a Magnolia Content type. A data source defines how content type items are persisted.


  $type: jcrContentTypeDatasource
  workspace: tourguides
  autoCreate: true

  nodeType: mt:tourGuide
    - name: birthday
      type: Date
    - name: gender
    - name: shortBio
Property Description



The type of the data source.

If the value is contentTypeDatasource, the definition must implement NorsuDataSourceDefinition. If the value is jcrContentTypeDatasource, the definition must implement JcrDataSourceDefinition.



The name of the workspace to store the content items.

When the definition item is loaded, and if there is no workspace registered by the given name and the autoCreate property is set to true, the system will register the workspace.


optional (only for JCR definitions)

A list of JCR namespace names.


A JCR namespace name.

When the definition item is loaded, and if the given JCR namespace hasn’t been registered yet, the system will register the namespace.

The namespace name must comply with the rules for XML namespaces, see W3C recommendations about Declaring Namespaces and Common Syntactic Constructs.


optional, default is false

If set to true, the following modifications will take place in the entire content type definition.

  • Workspace

    • Register the content workspace defined by the workspace if it hasn’t been registered yet.

  • Namespace (JCR-only content type definitions)

    • Register the JCR namespaces defined by the namespaces property if they haven’t been registered yet.

    • Remap the namespace prefix to the new namespace URI if the namespace URI has been modified.

    • Re-register the namespace if the namespace prefix has been modified.

  • Node type (JCR-only content type definitions)


optional (only for JCR definitions)

The path to an CND file which defines a JCR node type definition. The file must be a Magnolia Resource.

When the definition item is loaded, and if the node type defined in the file is not yet registered, the system will register it. (See Using the nodeType definition.)

JCR name spaces, node types and node type definitions

The model, explained in more detail on the Content type Model definition page, defines which nodeType is used. The model itself does not define the nature of the node type. In the example above the nodetype chosen is mt:tourGuide.

Let’s assume that the mt:tourGuide nodetype has not been registered yet. How to make sure that the model can utilize it?

There are two approaches.

  • All specifications in the YAML file.

  • Using the the nodeTypeDefinition property and a CND file for the node type definition.

All specifications in the YAML file

The example above defines all the JCR parameters in one YAML file. In most cases this is the recommended approach.

  • Namespace

  • Node type

If you intend to use a JCR namespace that hasn’t been defined yet, you can define the new namespace, for example mt, with the namespaces property.

In the above example, assuming that mt:tourGuide has not been registered yet, the system will automatically register a new node type with the given namespace mt, and the new node type inherits from the Magnolia mgnl:content node type.

Using the nodeTypeDefinition and CND node type definition file

With the nodeTypeDefinition property you can define a path to a CND file to define a JCR node type definition.

What is CND - Compact Namespace and Node Type Definition

Applies to JCR-oriented definitions only.

The Compact Namespace and Node Type Definition (CND) notation provides a compact standardized syntax for defining node types and making namespace declarations. The notation is intended both for documentation and for programmatically registering node types. See for more details.

While XML-based node type definitions are still supported, we recommend using CND.

Using a CND file allows you to define various JCR namespace and node type definitions. Node type definitions based on a CND file can be more complex than the automatically generated node types, which inherit from mgnl:content automatically.

Example of a CND-based node type definition


<mt = ''>

[mt:traveller] > mgnl:content

[mt:tourGuide] > mt:traveller

[mt:happyCustomer] > mt:traveller

Example of a content type definition referencing an CND-based node type definition:

  $type: jcrContentTypeDatasource
  workspace: happycustomers
  autoCreate: true
  nodeTypeDefinition: /content-type-examples/jcr-node-type-files/travellers-node-types.cnd

  nodeType: mt:happyCustomer
    - name: country
    - name: age
      type: Double
The CND node type definition resource is loaded only if the CND resource is referenced in the Data source definition of a Content type definition.

JCR security

Access to JCR workspaces is controlled by role-based access control lists (ACLs).

When the system detects and registers a new JCR workspace from a data source definition, it also automatically updates the superuser role by adding an ACL for the given workspace and granting read/write permissions for the / path.

In a production system, if you want to provide anonymous website visitors with (read) access to a specific JCR workspace, you must update the anonymous role by adding an ACL for the workspace.

For further information please read:

Interfaces and classes

The DatasourceDefinition interface is agnostic of any data source type.

CDS content

For CDS (ContentDataSources) content, Magnolia provides the NorsuDataSourceDefinition interface and the ConfiguredNorsuModelDefinition implementation class to specify the model to be mapped to CDS content.

JCR content

For JCR content, Magnolia provides the JcrDataSourceDefinition interface and the ConfiguredJcrModelDefinition implementation class to specify the model to be mapped to a JCR node.


DX Core



This widget lets you know where you are on the docs site.

You are currently perusing through the DX Core docs.

Main doc sections

DX Core Headless PaaS Legacy Cloud Incubator modules
6.3 beta

Magnolia 6.3 beta

Magnolia 6.3 is in beta. We are updating docs based on development and feedback. Consider the 6.3 docs currently in a state of progress and not final.

We are working on some 6.3-beta known issues during this phase.