Multichannelling aware Content Repository

This section describes how to publish a node and all of its channels into the same content repository.

This feature is a purchasable addon that needs to be activated for your Gentics CMS license key by Gentics Support.

1 Gentics CMS Integration

The Multichanneling Content Repositories can be used after enabling the multichannelling_contentrepository feature. Once enabled it is possible to create Content Repositories that are multichanneling aware.

1.1 Checking for removed objects

Every publish run will check for objects, that need to be removed from the Content Repository. For Multichannelling Content Repositories, it is possible to define, whether this check shall be done differentially (which is the faster option) or fully (which is slower but safer). Generally, it is recommended to have the checks done differentially.

2 Database structure

For a multichannelling aware content repository, the following extended database structure is necessary:

2.1 Table channel

The table channel stores hierarchical information about the nodes and channels contained in the content repository.

The tree structure of nodes and channels will be stored according to Modified preorder tree traversal. There will always be a dummy root node with id 0. All master nodes contained in the content repository will be direct children of the dummy root node.

The table has the following columns:

column type description
id integer ID of the node/channel
name string Name of the node/channel
mptt_left integer Left boundary
mptt_right integer Right boundary
updatetimestamp integer timestamp of the last update in this channel

2.2 Table contentobject

The table contentobject stores all available object types (like “page”, “file” and “folder”)

column type description
name string Name of the object type
type integer numerical type

2.3 Table contentattributetype

The table contentattributetype stores the meta data about available attributes.

column type description
name string Name of the attribute
type integer Datatype of the attribute (see below for Available datatypes)
optimized boolean Set to 1 for attributes, that are optimized. Optimized attributes will also be stored in the table contentmap
quickname string Name of the column to store the attribute value in table contentmap (if the attribute is optimized)
multivalue boolean Set to 1 for multivalue attributes. Multivalue attributes cannot be optimized
filesystem boolean Set to 1 for attributes, that have their values stored in the filesystem, instead of the database. This is only possible for the datatypes 5 and 6 and not in combination with optimized
linkedobjecttype type Object type of the linked objects (for datatype 2 or 7)
foreignlinkattribute string Name of the attribute of the linked object type, that reverses this attribute, if the datatype is 7
foreignlinkattributerule string Rule for restricting the matching linked objects, if the datatype is 7
2.3.1 Available datatypes
datatype name description
1 Text (short) Short texts of up to 255 characters
2 Object Link Links to other objects
3 Integer integer values
5 Text (long) Long text values
6 Binary binary values
7 Foreign Link “logical” datatype, that collects all objects of another type, which link to this object (in the specified attribute)
8 Long long values
9 Double double values
10 Date date values

2.4 Table object_attribute

The table object_attribute stores the assignment of attribute types to object types

column type description
object_type integer Object type (references contentobject.type)
attribute_name string Attribute name (references contentattributetype.name)

2.5 Table contentmap

The table contentmap stores the objects contained in the content repository. For every object (page, image, file or folder), the table will contain a single row for each node/channel.

Objects that are inherited from master nodes will also be stored as separate rows, even if it contains redundant information.

column type description
id integer Internal ID (auto increment)
channel_id integer ID of the channel, the object belongs to. References column channel.id
channelset_id integer ID of the channelset. Objects that are inherited from master nodes or are localized (locally overwritten) will share the same channelset_id
obj_id integer ID of the stored object (e.g. the page id in the backend database)
obj_type integer type of the object. References contentobject.type
contentid string content ID (constructed as [obj_type].[obj_id])
updatetimestamp integer Timestamp of the last update to this object (or any of its attributes)
quick_… various various quick columns (one for each optimized attribute

2.6 Table contentattribute

The table contentattribute stores the attribute values of objects.

column type description
id integer internal ID of an attribute value (auto increment)
map_id integer ID of the contentmap entry, the attribute value belongs to. References contentmap.id
name string Name of the attribute. References contentattributetype.name
sortorder integer Sortorder of the attribute value. This will be 0 for values of singlevalue attributes. For multivalue attributes the sortorder values define the ordering
value_text string Column for storing short string values (datatypes 1, 2). For filesystem attributes, this column will contain the path to the data file
value_int integer Column for storing integer values (datatype 3)
value_blob binary Column for storing binary values (datatype 6)
value_clob string Column for storing long string values (datatype 5). For filesystem attributes, this column will contain the MD5 sum over the data file
value_long long Column for storing long values (datatype 8). For filesystem attributes, this column will store the length of the data file
value_double double Column for storing double values (datatype 9)
value_date date Column for storing date values (datatype 10)
updatetimestamp integer timestamp when the attribute value was changed the last time

3 Referential integrity

The database structure contains some foreign key constraints to ensure data integrity. All foreign key constraints are created with the action CASCADE for delete or (when supported) update actions. This means that if the referenced column is deleted, all referencing columns will also be deleted.

Referential integrity with cascading actions will make some simple delete statements very powerfull: If for instance an entry in the table channel is removed, all objects, which are stored in this channel will also be removed, together with their attribute values. If an entry in table contentobject is removed (an object type), this will automatically remove all assignments to attribute types, all objects of that type and all attribute values.

When attributes store their values in the filesystem, and the attribute value is removed from the database by issuing SQL statements, the data file will NOT be removed from the filesystem. Therefore it is strongly discouraged to modify data in a content repository directly, unless it is absolutely necessary.

4 Efficient storage of filesystem attributes

Attributes of type 5 (long text) and 6 (binary) can be configured to store their data in the filesystem, instead of in the database (see Filesystem Attributes for details).

Filesystem attributes in a multichannelling content repository will be stored efficiently for objects that share the same content. If the data of an attribute is identical to the data of another filesystem attribute, the file will not be stored again, but a hardlink to the already existing attribute file will be created. This saves disk memory, because hardlinks share the same physical data on the disk.

For example, if a node and 10 channels are published into a content repository and no files are localized (all inherited), the binary data would be stored in 11 hardlinks to the same content on the disk, instead of 11 different (but identical) files. It is therefore strongly recommended to at least store the attribute binarycontent for files and content for pages in the filesystem.

The pulish process must check for files having identical content that can be reused by creating a hard link, when writing data into filesystem attributes. Depending on the speed of the filesystem (which may be mounted from another deviced and therefore accessed over the network), this may consume some time. To improve the publish performance, the mapping of attribute content (represented by the md5 sum and the length) to a data file is cached in an extra cache region gentics-mccr-fsattrfiles.