Synchronization

This topic describes the synchronization procedure in Optimizely. 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

The synchronization engine runs during site initialization, and creates a content type in Optimizely CMS for each ContentType attributed class found in assemblies. 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 application, 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, configure ContentModelOptions.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 content 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.

Related topics

Blog posts

• Finding content type conflict reasons by Māris Krivtežs