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.
The check in process lets you check In an object, such as an entity, or an entire diagram, when you are done working with it. ER/Studio Data Architect attempts to merge all of your modifications into the Repository. If there are any conflicts during the merge process, you are prompted to resolve them. After you have resolved 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 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 several 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 have deleted some objects, when you checks 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 will create a new version of the attribute that does not contain the binding. This is because deleting a Data Dictionary object causes all bindings to it to be removed. 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 will appear between the user's version of the attribute and the version of the attribute created by the Repository server. You should simply select the ER/Studio Data Architect version of the attribute to keep your changes.
This behavior can also occur when you checks in a Data Dictionary with a modified Data Dictionary object. For example, say you change the data type of an Attachment, then checks 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.
- 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.
- Save the changes you have made to the diagram; choose File > Save.
- Click the object you want to check in or CTRL-click several objects to check in more than one.
- Right-click and select Check in.
- Depending on what you have selected, the check-in option on the short menu may be: Check in Diagram, Check in Model, Check in Submodel, Check in Object(s), Check In Data Dictionary, Check In Data Dictionary Object(s), 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 selected Review changes before check in or if a conflict is detected, you will be prompted to resolve the differences between your version and the version on the Repository.
Change and Conflict Categories
The following 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. |
- 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.
Resolving Check-in and Merge Conflicts
The following describes the logic behind conflict detection resolutions:
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 have been made to a model. There are three general types of Repository conflicts:
- An item was updated in a local copy but deleted in the Repository version.
- An item was deleted in a local copy but updated in the Repository version.
- An item was updated in a local copy and was updated differently in the Repository version.
Conflicts of type 1 and 2: Have a check box, which if selected indicates that the local version will be applied. (You can view the properties of the item or table updated in the local diagram by expanding the item. Only those properties that have been updated will be displayed).
If you select the check box of this conflict item, Table A will be applied to the local and the Repository version of the diagram; the table will not be deleted. However, if the user clears the check box, the remote version of the diagram will be applied to the local version - the table will be 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 will be displayed. If you select the check box of the conflict item, the local version will be applied - the table will be deleted in the local version and the Repository version of the diagram. If you do not select the check box, the table will be updated in the local version of the diagram.
Conflicts of type 3: the Review Changes and Resolve Conflicts dialog box will display each new name underneath the table conflict item. The first name property item (new name item) will display the local value for the table name (i.e. the name decided upon by the local user). The second item will display 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 will be applied to the Repository and the local ER/Studio Data Architect version. If you select the Repository version, that name will go into effect in the local version of the diagram (and stay in effect in the Repository).
Common check-in conflicts and their resolution are summarized in the table below.
|
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. |
Notes
- 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, they are assumed to refer to the same column in the database. Occasionally ER/Studio Data Architect will change 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 be able 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 and 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.