What do i need to know about the Content.Repository Structure

This FAQ will answer questions around the topic of the Content.Repository structure and data integrity.

1 What issues will be checked using the backend checks in the Content.Repository view?

1.1 Check / Repair:

This check will verify the existing of mandatory tables and columns. The repair functionality will automatically recreate missing tables. Please note that quickcolumns are not being checked using this option.

Additionally the integrity of the Tagmap is being checked to ensure that there are no conflicts for entries with the same mapnames and optimized-, multivalue-, attribute type option.

1.2 Check data / Clean data:

This check check and optionally remove objects that are not published. The check works for folders, pages and files. This check is useful if you disable update functionality for your Content.Repository or when you work with a new backup.

The output of the data check lists the incorrect objects along with the reason why they are incorrect. Please note that in order to save performance the reason is ommitted for some objects.

2 What will be checked using the CRSync (Sanitycheck2)?

Similar to the Check / Repair functionality the table and column structure will be checked. Missing columns will be recreated when the autorepair2 flag was set.

Additionally the quick columns will be checked. For each contentattributetype that was marked as optimized a matching quick column with indices must exist. The datatype, indices, default values, name and nullable option will be checked.

3 How do i create a new CR?

New CRs can be created using the CRSync sanitycheck2 & autorepair2 option or using the Check / Repair option within the backend. If you chose the Backend method you just have to create an empty database and setup the jdbc url in the backend Content.Repository view.

4 How can CRs be repaired. How can the structure be kept uptodate?

The structure can be updated using the CRSync autorepair2 feature. Set the sanitycheck2 and autorepair2 flag for the source and target repository in order to verify the structure for both repositories.

5 Attribute Types

The following table summarizes the types of attributes in a Content.Repository

Type Stores Database Column
[1] Text (short) Short text (up to 255 characters) value_text
[2] Object References to other objects value_int
[3] Integer Integer values value_int
[5] Text (long) Long text value_clob
[6] BLOB Binary data value_blob
[7] Foreign Link Opposite of an object link (contains no data)

Deprecated attribute types

Type Stores Database Column
[4] Binary Binary data value_bin

5.1 Changing of attribute types

In some cases, it might be necessary to change the type of an attribute. E.g. some very old installations might still use Content.Repositories that have the attributes content and binarycontent set to type [4] Binary. If this is the case, it is recommended to migrate the Content.Repository to the new structure.

The following steps can be done to migrate the Content.Repository with minimum downtime for the frontend implementation:

  1. Create a new (empty) database in the database server
  2. Create a new Content.Repository in the CMS with the url pointing to the new (empty) database
  3. Create all required attributes in the Content.Repository
  4. Use the Repair function to create the table structure
  5. Assign the Node(s) to the new Content.Repository
  6. Republish all published objects for Nodes assigned to the new Content.Repository (using the maintenance), so that the new Content.Repository will be filled
  7. (Optional) Establish CRSync to new frontend Content.Repository
  8. Reconfigure frontend applications to use the new Content.Repository