Chapters1 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:
- Create a new (empty) database in the database server
- Create a new Content.Repository in the CMS with the url pointing to the new (empty) database
- Create all required attributes in the Content.Repository
- Use the Repair function to create the table structure
- Assign the Node(s) to the new Content.Repository
- Republish all published objects for Nodes assigned to the new Content.Repository (using the maintenance), so that the new Content.Repository will be filled
- (Optional) Establish CRSync to new frontend Content.Repository
- Reconfigure frontend applications to use the new Content.Repository