Synchronization

During website initialization, the synchronization engine scans and validates available content types and properties created in code or from the Optimizely Content Management System (CMS) admin view.

The synchronization engine runs during site initialization and creates a content type in 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. CMS stores additional settings defined in the code 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 decorated with the ContentType attribute to the synchronization engine.

The properties of a class determine the properties of a content type. You create a property on the content type for each public property with the 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 the fact 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 assembly's major and minor version numbers containing the content type are smaller than the major and minor version numbers that committed changes to the databases during a previous synchronization.

3. Commit 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 displays on content types to allow for more granular synchronization. Synchronization performs the following operations.

   • Create a content type or property – Synchronization stores only enough information to fulfill the database constraints and to associate the row with the class or class member from which it originated. It stores the remaining class settings in a separate, in-memory repository available when the content type or property is cached.
   • 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.
   • Rename properties – A class property can change for the following reasons.
     • You renamed a property.
     • You added a property and removed another.
       Synchronization handles either case as a new property, so it does not transfer values to the new property. If you want to rename a property and transfer values to the new property, implement a MigrationStep. See Refactor content type classes.
   • 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 created in admin view.
     • You remove a content type only if no instances for the type exist in the database.
     • You remove a property only if it has no values set.

4. Merge database settings.
   Synchronization adds a content type or property definition object to the 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 with attributes) to form the actual object the application uses. 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 the code, and those settings still apply after the application restarts.

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

Blog posts

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