Synchronization

Table of contents

• Introduction
• Synchronization process

Introduction

The detection of code-defined content types is handled via annotation using class- and property attributes. During site initialization all assemblies in the bin folder are scanned and all classes decorated with the [ContentType]-attribute are passed to the synchronization engine.

The synchronization engine will create a content type in CMS for each class found in code. The content type created in the database only contain the information required to fulfil the database constraints and be able to associate the row in the database with the class, settings defined in code is stored in-memory.

To determine the properties that a content type should have, the properties of the class are considered. For each public property that have public get and set accessors a property on the content type will be created. The desired property settings can be specified in by using a set of property attributes.

Synchronization process

During site initialization, once the synchronization engine has been set up, the synchronization process begins. It is broken down into the following steps:

Validate

Before any other action is taken the models created from the classes are validated. This includes verifying that two models are not sharing the same GUID value.

Analyze

For each model defined in code we determine if it represents a new content type, if it is an updated version of an existing content type or if it identical to an existing content type. The same operation is done for each of the properties belonging to the model. In this step we also find any content types and properties in the database that no longer exist in code. If the version number of the assembly containing the content type is smaller than the version number that commited changes to the databases a previous synchronization then that content type will be ignored (only the major and minor part of the version number is respected).

Commit

If any new content types or properties were found we commit the changes to the database. You can disable the commit phase by setting enableModelSyncCommit to false on site settings, a new button Synchronize will appear on content types to allow for more fine grained synchronization. The different operations performed at this stage are performed as follows.

Creating a new content type or property

Only a small subset of the setting values specified in code are actually stored in the database. We only store enough information to fulfil the database constraints and be able to associate the row in the database with the class or class member from which it originated. All other setting values that are specified in the class are not saved in the database, instead they are stored in a separate in-memory repository to be when the content type or property is cached.

Updating a content type or property

Since only the minimum of information about page types and properties are stored in the database no update operations are performed at this stage. Changed settings values are instead handled during the merge operation that occurs right before a page type or property is cached, see Merge process.

Renaming properties

Renaming a property of class is an ambiguous change, one of two things may have occurred:

• A property was renamed.
• One new property was added and one other property was removed.

Always handle this as if a new property was added, in other words no values will be transferred to the new property. If the intention is to change the name and any values are intended to be transferred to the new property you need to implement a MigrationStep. See the Refactoring of content type classes article for more information.

Deleting content types and properties

If you find content types or properties in the database that no longer exist in code, try to delete them. Note that this only applies for content types and properties that once were auto-created, content types and properties created in Admin mode will never be deleted in this way.

• A content type will only be removed if no instances exist in the database for the type.
• A property will only be removed if no values have been set for that property.

When a content type or property definition object is loaded for the first time it is added to the runtime cache. At this point, before the item is cached, the settings stored in the database (in other words settings made in Admin mode) and settings defined in code (in other words set via attributes) are merged to form the actual object that will be used by the application. The setting values in the database have precedence if the model and database settings are in conflict. This means any settings you save via the Admin mode UI will override settings defined in code and those settings will still apply after the application restarts.

The Revert to Default button when editing properties and content types will remove all settings previously saved via Admin mode and make all the settings specified in code apply again.