Sync Task Aspects

Based on the relational model data elements in the project and the selected sync sources for these elements, the designer creates Sync Tasks, which are shown in the Available Sync Tasks area in the Sync Relational Model Data tab.

Order in which operations take place

If a project has multiple databases in the project or several schemas with different sync sources, the order in which operations are performed through the tasks is as follows:

1. The schemas with Mixed / Database are refreshed from the database server.
2. The entity model is migrated to the new metadata after the sync task. This affects only the elements mapped onto elements in the refreshed relational database elements
3. The schemas with Mixed / Model will get their tables synchronized with the entity model as it is now.

This guaranties that with multiple databases one is leading and one follows, and it's very likely the database sourced one is leading (as that's updated externally, so sourced from elsewhere).

What work is done for each sync task.

There are two different sync tasks: Sync with the model and Sync with a database. When syncing, you perform zero or more instances of these tasks. Below the sub-steps for each task are described. If multiple Sync with a database tasks are enabled, the Relational model data retrieval wizard will appear multiple times, once for each task, as each task requires connection to a different database type and driver.

Syncing with a model

It controls the various sub tasks to perform for the synchronization of the relational model data with the model. The following functionality is performed by this task

Auto-map unmapped entities

This is the feature which automatically maps entities onto new or existing targets. It only creates new tables if the schema's sync source is set to Model or Mixed. It tries to find existing elements using the naming rules defined in the Project Settings. If no match is found, a new element is created.

Auto-map unmapped entity fields

This is the feature which automatically maps entity fields onto new or existing fields. It only creates new table fields if the schema the table is in has its sync source to Model of Mixed. It tries to find existing elements using the naming rules defined in the Project Settings. If no match is found, a new element is created.

Sync names of tables and fields

This is the feature which synchronizes names of tables and table fields with the mapped entities and entity fields. It proceeds if the project setting SyncRelationalModelDataElementNameWithTargetElementName resolves to true, otherwise it's a no-op.

Sync nullability of fields

This is the feature which reflects nullability of fields in the entity model with the mapped target fields, if they're in a table in a schema with sync source set to Mixed or Model. It proceeds if the project setting ReflectNullabilityOfElementFieldInTargetField resolves to true, otherwise it's a no-op.

Sync types of fields

This is the feature which reflects the types of fields in the entity model with the mapped target fields, if they're in a table in a schema with sync source set to Mixed or Model. If proceeds if the project setting ReflectTypeOfElementFieldInTargetField resolves to true, otherwise it's a no-op.

Perform meta-data adjustment

This is the feature which performs the actual meta-data adjustment for elements like Primary keys, Foreign Key Constraints, Identity flags and the like. It will only perform the actions on the schemas which have their sync source set to Model or Mixed. It won't make exceptions which elements are synced: the model is the source of truth so if elements in the relational model data aren't matching the model, they'll be altered and if necessary, marked for deletion.

Syncing with a database

It controls the various sub tasks to perform for the synchronization of the relational model data with a database. The following functionality is performed by this task.

Auto-map unmapped entities

This is the feature which auto-maps existing entities on existing targets in the database associated with the task (the 'Involved elements'). It is run after the rest of the work has been performed.

Obtain meta-data from the database

This is the feature which obtains the meta-data from the database system tied to the task through the DriverID. This uses the Relational model data retrieval wizard.

Migrate model to new populated catalogs

This is the feature which migrates the existing model mapped to the old relational data which has been replaced by new elements, to the new elements obtained from the database by the task.

Sync and model errors

Syncing a catalog with a model with errors

If the entity model contains one or more errors, it's still possible to sync relational model data with a database: for relational model data which is synced from a database, the model elements follow the meta data obtained from the database, so if there are errors in the model elements, they'll be either corrected after the migration or they're still there and the user has to correct them then.

Syncing relational model elements from a model with errors

The entity model can contain one or more errors, e.g. errors with types not matching with mappings, an entity doesn't yet have fields or a mapping or a field e.g. misses a type. These errors either are solved by syncing or they'll never be solved by syncing so they'll stay after the synchronization and the user has to solve them then. This means that the sync will proceed and the designer will try to perform as much work as possible.

If errors are still present after the sync, the sync couldn't solve them and the user has to solve them prior to generating code. With the Designer's real-time validation, the errors will be found immediately.

Sync and typed views mapped on tables

Only entities and their mappings are taken into account when syncing tables with model elements: typed views are not considered. The main reason is that typed views are read-only constructs which follow the database and in fact are projections of the table model for fetch purposes. As such they're not part of the abstract entity model which is projected onto the relational model.

This means that if a typed view and an entity are mapped onto the same table and the typed view has different types or nullability defined for a given set of fields, these types/nullability flags are ignored, only the entity fields are taken into account.

Cleaning up orphaned relational elements

Cleaning up orphaned relational model data elements is a feature which automates maintenance on relational model data elements based on existing mappings. Its process is controlled by the Project Settings, namely ExcludableOrphanedElementDetectedAction and NonExcludableOrphanedElementDetectedAction.

These settings allows you to automatically mark elements for deletion, however for schemas which are synchronized with a relational database this works a bit differently:

• 'Marked for deletion' is ignored for schemas which are synced with a DB, and for elements other than tables in schemas which have sync source set to 'Mixed'.
• The suggestions in the errors and warnings have to make sure that the user can't mark the element for deletion in schemas synced with a database.
• A field's mark for deletion directive is changed into 'RaiseWarning' if the table is in a schema with sync source set to database.

Undo / redo and backup of the project

The sync process is not an action you can 'undo' through the Designer's undo/redo system. Instead, the sync process creates a backup for the project prior to starting the first Sync Task: the project is saved into a backup file, into the folder specified in the Default Backup folder, specified in the Designer Preferences, under 'Designer Behavior'. If you don't want to create a backup before sync, set the Designer Preference setting Create backup before relational model data sync to false.