This content has been marked as final. Show 7 replies
Merging is not simple logic as we thot.
Merge Rules and Behavior for Full Merges
For full merges, the following general rules are applied:
•It is assumed that you generally want to keep the changes in the modified repository. For example, if an object is added to or deleted from the modified repository, the object is added or deleted without prompting.
•If an object is added to or deleted from the current repository, the Merge Repository Wizard asks whether you want to keep the changes.
In general, the Merge Repository Wizard tries to ensure that you have the minimum set of objects necessary to service your queries. During a merge, there might be objects introduced by the current repository that are not needed in the merged repository. To address this issue, the Merge Repository Wizard asks whether new Presentation layer objects in the current repository are needed in the final merged result. If you choose to keep the new presentation objects, all the dependent logical and physical objects are added as well. However, if you choose not to keep the new presentation objects, then the dependent logical and physical objects are not kept, because no queries will require the use of these objects. The Merge Repository Wizard discards these objects to ensure that the merged repository does not get populated with unused objects.
•If an object is added to or deleted from both repositories, the object is added or deleted without prompting. If the same object was added with slight differences in its properties, the Merge Repository Wizard asks which version of the properties you want to keep.
•If an object has been modified only in the current repository, or only in the modified repository, the change is kept. If the same object is modified in both the current and modified repository, and the changes are different, then there is a merge conflict. When conflicts occur, the Merge Repository Wizard asks you to choose which change you want to keep.
•Making a decision about one object can determine a whole set of decisions, depending on the object relationships involved. For example, if you choose to keep a presentation column that has been added to the current repository, then the associated presentation table and subject area must also be kept, along with the logical column, physical column, and other associated objects upon which it is based. Alternatively, if you choose not to keep a subject area that has been added to the current repository, then you are not prompted to choose whether to keep its associated objects. Adding a join may require the addition of its base tables, while changing an expression may cause physical columns to be added.
•Object relationships can be interconnected through their properties. In addition to strings and numbers, the internal value of a property can be other repository objects. Because of this, a change to one object might cause a corresponding change to an interrelated object.
For example, assume you change the data source of Init Block B from a connection pool to Custom Authenticator A. In addition to the data source property change to the initialization block object, a corresponding property change occurs in the custom authenticator object (because the value of the initialization block property for Custom Authenticator A is now Init Block B).
Because the decisions made for these properties must be synchronized, if you select Current as the decision for the data source property of Init Block B, then the decision for the initialization block property of Custom Authenticator A will also be Current. See Figure D-1 shows what this example looks like in the Merge Repository Wizard.
Test each and every steps. Always keep Original Repository as baseline.
Mark if correct/Helps