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. Additional settings defined in the 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 decorated with the ContentType attribute to the synchronization engine.

The properties of a class determine the properties of 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 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 content types and properties.
   Synchronization commits any 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. The following operations are performed at this time.

   1. Create a 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 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.

   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 Refactor content type classes.

   1. 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 the admin view.

      • A content type is removed only if no instances for the type exist 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 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 via 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 code, and those settings still apply after the application restarts.

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

See also blog post: Finding content type conflict reasons by Māris Krivtežs