Synchronization

This topic describes the synchronization procedure in Episerver. During website initialization, the synchronization engine will scan and validate available content types and properties created in code or from the CMS admin view.

How it works

If the synchronization engine is set up, the synchronization process begins during site initialization. The synchronization engine creates a content type in CMS for each class found in code. The content type created in the database contains only the information required to fulfill the database constraints and to associate the row in the database with the class. Additional settings defined in code are stored in-memory.

Annotation detects code-defined content types by using class and property attributes. During site initialization, annotation scans assemblies in the bin folder, and passes classes that are decorated with the [ContentType]-attribute to the synchronization engine.

The properties of a class determine the properties for a content type.  A property is created on the content type for each public property with public get and set accessors. To specify property settings, use property attributes.

Synchronization procedure

Synchronization consists of the following steps.

1. Validate the models.

   Synchronization validates the models created from the classes, including that two models do not share a GUID value.

2. Analyze the content types and properties.

   Synchronization determines whether each model defined in code (and its properties) is one of the following criteria:

   • the model is a new content type
   • the model is an updated version of an existing content type
   • the model is identical to an existing content type

   Synchronization also finds content types and properties in the database that no longer exist in code. Synchronization ignores the content type if the major and minor version numbers of the assembly containing the content type is smaller than the major and minor version numbers that committed changes to the databases during a previous synchronization.

3. Commit new content types and properties.

   Synchronization commits any new content types or properties to the database. To disable the commit phase, go to app settings in the web.config file and set enableModelSyncCommit to false. The Synchronize button appears on content types to allow for more granular synchronization. The following operations are performed at this time.

   1. Create a new content type or property.

      Synchronization stores only enough information to fulfill the database constraints and to associate the row in the database with the class or class member from which it originated. It stores the remaining class settings in a separate, in-memory repository that is available when the content type or property is cached.

   2. Update a content type or property.

      The merge operation updates changed settings. The merge operation occurs right before a page type or property is cached. See Merge database settings.

   3. Rename properties.

      A class property can change for one of the following reasons.

      • A property was renamed.
      • A new property was added, and another was removed.

      Synchronization handles either case as a new property, so no values are transferred to the new property. If you want to rename a property and transfer values to the new property, implement a MigrationStep. See Refactoring content type classes.

   4. Delete content types and properties.

      Synchronization deletes automatically created content types or properties in the database that do not exist in code. Synchronization does not delete content types and properties that were created in admin view.

      • A content type is removed only if no instances for the type exists in the database.
      • A property is removed only if no values are set for it.
4. Merge database settings.

   Synchronization adds a content type or property definition object to runtime cache when it loads for the first time. Before the item is cached, synchronization merges the settings stored in the database (settings made in admin view) and settings defined in code (set via attributes) to form the actual object used by the application. If the model and database settings conflict, the database setting values take precedence; any settings you save through the administrative interface override settings defined in code, and those settings still apply after the application restarts.

   When you edit properties and content types, the Revert to Default button removes settings that were previously saved through the admin view and reapplies settings that were specified in code.