Performing Adoption › Preparing for Adoption › Identify Objects to Rename Prior to Adoption › Example Where Overwriting Common Ancestry Would Occur

Example Where Overwriting Common Ancestry Would Occur

Consider the scenario where CLIENT in the destination model has the same name as CLIENT in the source model, but CLIENT in the destination model shares common ancestry with CUSTOMER in the source model. The two objects named CLIENT cannot be logically the same. You can be sure such objects are not meant to be equivalent.

When the Compare process reports that CLIENT does not exist in the destination model, it means that no object in the destination model has an Original Encyclopedia ID and Original Object ID that matches CLIENT's in the source model.

For the Compare process to report two objects as different, they must be equivalent but last changed at different times, as indicated by the date and time of their respective session objects. It can be assumed from this that CLIENT in the destination model has an Original Encyclopedia ID and Original Object ID that matches CUSTOMER's in the source model.

Note: Adoption should not be performed on CLIENT.

The following figure shows what would happen if adoption were performed on CLIENT. (Adoption would succeed because Adoption would find an entity type named CLIENT in the source model and assign this object's IDs to CLIENT in the destination model.) Adoption of CLIENT in the destination model would result in overwriting the common ancestry between CLIENT and CUSTOMER.

The general rule is to avoid performing adoption between two objects with matching names when one of the objects shares common ancestry with another object with a different name. This guideline expressed in terms of the Compare Report would be—Never attempt adoption of an object listed in the Different section of the Compare Aggregate Object Report.