Saving Changed Items to the Repository (Checking In)
Go Up to Working with Objects in the Repository
Contents
The check-in process synchronizes the changes made to the local checked-out item with the Repository version. This process lets you check in an object, such as an entity or an entire diagram, once you are done working with it. ER/Studio Data Architect attempts to merge all of your modifications into the Repository.
You are prompted to resolve any conflicts that are discovered during the merge process. After you resolve all conflicts and the merge is complete, the merged results are added to the repository and your diagram. The merged results are added to your diagram so that it remains synchronized with the file in the repository.
Checking In Objects
When you check in an object, all of the object's structural and referential integrity (RI) dependencies are checked in as well. You can check in a newly-created object (i.e. an entity which you added to a checked-out diagram) or multiple, selected objects at one time to the repository.
The Repository enforces the following rules when checking in individual objects to help maintain integrity throughout the diagram:
- If you have an object and one or more of its dependencies checked out separately, then when you check in the main object, all of its dependencies are also checked in.
- If you deleted some objects, when you then check in a modified object, all of the deleted objects are also checked in to the repository, regardless of whether they were associated with the modified object.
- If you check in a data dictionary object that is bound to an attribute, and changes to the data dictionary object affect the attribute, then the attribute is marked for a delayed check out.
Checking In a Data Dictionary
When you check in a Data Dictionary, the Repository server may create new versions of objects that were bound to individual Data Dictionary objects. For example, if you check in a Data Dictionary after deleting a user Datatype, and the user Datatype was bound to an attribute, the server creates a new version of the attribute that does not contain the binding. This is because deleting a Data Dictionary object causes the removal of all bindings to it.
The new version is reflected in the Version History for the attribute, with an automatically-generated comment. When the user does a Get Latest Version on the affected attribute, the new version without the binding is placed in the user's copy of the Diagram. If the user modifies or deletes the affected attribute before checking in the Data Dictionary, then a merge conflict appears between the user's version of the attribute and the version of the attribute created by the Repository server. Simply select the ER/Studio Data Architect version of the attribute to keep your changes.
This behavior can also occur when you check in a Data Dictionary with a modified Data Dictionary object. For example, say you change the data type of an Attachment, and then check in the Data Dictionary to which it belongs. Any objects bound to that Attachment must have the value override removed because the value override is only valid for a particular Attachment data type. This means that the objects (which can be in the Data Dictionary or the Diagram) that are bound to that Attachment get a new version in the Repository that reflects the removal of the object's value override.
If you made changes to the Data Dictionary, you need to check in the Data Dictionary before checking in the diagram. For example, if you create a domain in the Data Dictionary and use that domain in the diagram, if you check in the diagram before the Data Dictionary, ER/Studio Data Architect produces errors.
Note: If conflicting changes are detected because multiple people changed the diagram, ER/Studio Data Architect opens the Review Changes and Resolve Conflicts dialog, where you must resolve any conflicts between the local and remote diagrams before continuing.
Checking In to the Repository
The procedure to check in an object into the Repository is basically the same for all object types.
To check into the Repository
- Save the changes you have made to the diagram by selecting File > Save.
- Click the object you want to check in or CTRL-click several objects to check in more than one.
- Right-click, and then select Check in. Depending on what you selected, the check-in option on the short menu may be one of the following: Check in Diagram, Check in Model, Check in Submodel, Check in Object(s), Check In Data Dictionary, Check In Data Dictionary Object(s), of Check In Source/Target or Check In Data Flow.
Note: Checking in the Data Dictionary also checks in any Data Movement Rules defined on the Data Lineage tab.
- Complete the Repository Check In dialog as required, and then click OK to start the check-in process.
If you select Review changes before check in or if a conflict is detected, you are prompted to resolve the differences between your version and the version on the Repository.
Change and Conflict Categories
In general, the most effective and safest way to handle changes you do not recognize or remember making is to allow them to be checked in to the Repository. Only changes that you make but later decide against should be unchecked.
The following table provides some additional information about the icons used on the Review Changes and Resolve Conflicts dialog to differentiate the differences detected and their default resolutions.
| Category Icons | Description |
|---|---|
|
|
Changes to the local diagram conflict with changes made by other users to the remote diagram in the Repository. These conflicts are changes that the user performed on items in the local diagram that were also changed by other users who already checked in their changes to the Repository. For more information on conflicts, see Resolving Check-in and Merge Conflicts. |
|
|
Additions to the local diagram to items were not otherwise modified in the Repository version by other users. These additions were made to the local diagram and do not conflict with any changes made to any remote diagrams. |
|
|
Deletions in the local diagram to items were not otherwise modified (in the Repository version by other users. These deletions were made to the local diagram and do not conflict with any changes made to any remote diagrams. |
|
|
Updates to the local diagram to items were not otherwise modified (in the Repository version by other users. These updates were made to the local diagram and do not conflict with any changes made to any remote diagrams. |
Resolving Check-in and Merge Conflicts
A conflict arises when there is a difference between the version in the Repository and the version checked out to a user. In these instances, you can resolve the data conflict by choosing to accept your version, the Repository version, or a combination of both. A common scenario arises when multiple, simultaneous changes are made to a model.
There are three general types of Repository conflicts:
- An item is updated in a local copy, but deleted in the Repository version.
- An item is deleted in a local copy, but updated in the Repository version.
- An item is updated in a local copy, but is updated differently in the Repository version.
Resolving Conflicts of Type 1 and 2
Conflicts have an associated check box, which if selected indicates that the local version is applied. You can view the properties of the item or table updated in the local diagram by expanding the item. Only those properties that are updated are displayed.
If you select the check box of this conflict item, Table A is applied to the local and the Repository version of the diagram and the table is not deleted. However, if the user clears the check box, the remote version of the diagram is applied to the local version, and the table is deleted in the local version of the diagram.
A converse example: an item is deleted locally but updated in the Repository. You can view the properties and the new table values (i.e., see how the table was updated by other users) by expanding the item. Only properties whose values changed are displayed. If you select the check box of the conflict item, the local version is applied and the table is deleted in the local version and the Repository version of the diagram. If you do not select the check box, the table is updated in the local version of the diagram.
Resolving Conflicts of Type 3
The Review Changes and Resolve Conflicts dialog box display each new name beneath the table conflict item. The first name property item (new name item) displays the local value for the table name, i.e., the name decided upon by the local user. The second item displays the new value for the table name as it appears in the Repository version of the diagram.
Each item has an option button. If you click the option button of the ER/Studio Data Architect version of the table name, the local name version is applied to the Repository and the local ER/Studio Data Architect version. If you select the Repository version, that name goes into effect in the local version of the diagram and stays in effect in the Repository.
Use the following table to understand common check-in conflicts and their resolutions.
|
Conflict |
Resolution | |
|---|---|---|
|
ER/Studio Data Architect |
Repository | |
|
Unchanged |
Modified |
Soft, does not show up in dialog, chooses Repository side. |
|
Unchanged |
Deleted |
Soft, does not show up in dialog, chooses Repository. |
|
Unchanged |
Unchanged |
Not a conflict, does not show up in dialog. |
|
Modified |
Unchanged |
Soft, shows up in dialog with Review Changes enabled, defaults to ER/Studio Data Architect. |
|
Deleted |
Unchanged |
Soft, shows up in dialog with Review Changes enabled, defaults to ER/Studio Data Architect. |
|
Modified |
Modified |
Hard, shows up in dialog, defaults to ER/Studio Data Architect. |
|
Modified |
Deleted |
Hard, show up in dialog, defaults to Repository. |
|
Deleted |
Modified |
No conflict, shows up in dialog with Review Changes enabled, defaults to ER/Studio Data Architect |
|
Does Not Exist |
New |
No conflict, does not show up in dialog, defaults to Repository. |
|
New |
New |
Not indicated as conflicts in dialog and are resolved either by renaming one of the objects in ER/Studio Data Architect, or by deleting one of the objects or properties. |
Note:
- Soft conflicts are shown in the Resolve Conflicts Dialog box when the Review Changes option is selected.
- Hard conflicts are shown regardless of the setting of the Review Changes option.
Sequence Number Changes and Other Automatically-Resolved Differences
In large, complex models there can be minor inconsistencies in the way the data is presented. These consistencies do not have a major effect on the data in the model, but they can appear as changes in the review changes dialog. For example, when two foreign key columns exist in a table and have the same name and are not rolenames, they are unified by ER/Studio Data Architect.
A column exists in the internal data for each relationship that propagates to the table, but only one is shown with that particular name. Which one is shown doesn't matter as they are assumed to refer to the same column in the database.
Occasionally, ER/Studio Data Architect changes which column it displays based on which internal ID is lower. If the two columns were added at different times and given different sequence numbers within the table, it is possible that when ER/Studio Data Architect switches which it displays, the ordering of the columns in the table changes. This can cause the sequence numbers of other columns to change as well. Those sequence number changes often show up in the dialog.
Although ER/Studio Data Architect is designed to handle the deselection of those extra changes, it is generally a better idea to let ER/Studio Data Architect update itself automatically. It updates the data so that it is consistent. Deselection changes in the dialog might undo some of the changes ER/Studio Data Architect makes, but not all. In addition, there are some inconsistencies that could lead to corrupted data that cannot be handled by ER/Studio Data Architect or its Repository Merge functionality.
Often, ER/Studio Data Architect can identify and correct these inconsistencies before they cause major corruption, but if you deselect the changes, they are not allowed to be checked in, and they are never fixed in the Repository.