Merge Rules and Behavior for Full Merges

Learn about the rules that apply to full merges.

For full merges, the following rules are applied:

  • Oracle assumes that you 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 if you want to keep the changes.

    The Merge Repository Wizard tries to ensure that you've the minimum set of objects necessary to service your queries. During a merge, it's possible that objects were introduced by the current repository that aren't needed in the merged repository. To address unwanted objects 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, the dependent logical and physical objects are also added. If you choose not to keep the new presentation objects, then the dependent logical and physical objects aren't kept. The Merge Repository Wizard discards these objects to ensure that the merged repository doesn't 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's 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 influence a whole set of decisions, depending on the object relationships involved. For example, if you choose to keep a presentation column that was added to the current repository, then the merge process keeps the associated presentation table and subject area, along with the logical column, physical column, and other associated objects upon which the presentation column was based. If you choose not to keep a subject area that was added to the current repository, you aren't prompted to choose whether to keep its associated objects. Adding a join might require the addition of its base tables, while changing an expression might add physical columns.

  • Object relationships are interconnected through their properties such as strings and numbers, and an internal value of a property that represent other repository objects. 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. The merge process requires synchronized decisions for these properties. 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 is also Current.

Special Merge Algorithms for Logical Table Sources and Other Objects

There are special rules for certain types of objects and situations that are in addition to the general rules governing how objects are merged and which situations require prompting.

This section contains the following topics:

Merge Objects that Use the Vector Merge Algorithm

Some objects such as levels, application roles, and object permissions, use a vector merge algorithm that determines the parent/child relationships between objects.

Objects that use the vector merge algorithm include:

  • Levels in a dimension, levels associated with a logical column, and child levels

  • Dimensions and tables in a logical display folder

  • Aggregation content in a logical table source

  • Security objects like user and application role membership and permissions

  • Initialization block LDAP server settings and processing precedence

The Oracle BI Server determines the initial state of object relationships in each repository during the merge process. For example, the following list shows the different possibilities for object permissions and how they relate to users and application roles:

  • M - Missing. The application role, user, or object isn't present in the repository.

  • D - Default. Permissions are inherited from the parent application role.

  • Y - Yes. The permission is explicitly granted to the user or application role.

  • N - No. The permission is explicitly denied to the user or application role.

The Merge Repository Wizard determines the appropriate relationship for the merged repository depending on the state of the object permission relationships in each repository. For example:

  • For an original repository with a result of Y, a modified repository with a result of N, and a current repository with a result of M, the Merge Repository Wizard determines a result of N for the merged repository.

  • For an original repository with a result of N, a modified repository with a result of Y, and a current repository with a result of M, the Merge Repository Wizard determines a result of Y for the merged repository.

Vector Merge Example: Merging Application Roles

The following list shows the different possibilities for user and application role relationships:

  • M - Missing. The application role or user isn't present in the repository.

  • Y - Yes. The application role or user is a member of the application role.

  • N - No. The application role or user isn't a member of the application role.

The table shows the merged result for different combinations of object relationships in the merging repositories.

Original Repository Modified Repository Current Repository Result

M

M

M

N

This situation can happen if neither the application role nor the user are present in the original repository, but the user is present in the modified repository and the application role is present in the current repository. In this case, no membership can be assumed.

M

M

Y

Y

M

M

N

N

M

Y

M

Y

M

M in original for this case implies that either the user or application role isn't present. The missing object added in both can't be considered the same object

Y

Y

Y

M

Y

N

Y

M

N

M

N

M

N

Y

Y

M

N

N

N

Y

M

M

Y

Y

M

Y

Y

Y

M

N

N

Y

Y

M

Y

Y

Y

Y

Y

Y

Y

N

N

Y

N

M

N

Y

N

Y

N

Y

N

N

N

N

M

M

N

N

M

Y

Y

N

M

N

N

N

Y

M

Y

N

Y

Y

Y

N

Y

N

Y

N

N

M

N

N

N

Y

Y

N

N

N

N

Merge Logical Table Sources

Special rules govern how to merge column mappings in logical table source objects. Each column mapping is merged individually.

For each column, if the mapping has changed in either the modified or current repository, the change is kept. If the mapping has changed in both repositories, the Oracle BI Server attempts to merge the mappings automatically.

The deletion of a column isn't considered to be a change in its mapping. If a column isn't present in the modified repository, then the mapping in the current repository is used instead.

If there are differences in aggregation content, then the aggregation content specified by level has priority. In other words, if the aggregation content in one repository is by level and the aggregation content in another repository is by column, then the aggregation content by level is retained.

Merge Security Filters

If a filter for an application role has changed in only one repository, then the change is kept. If the filter has changed in both repositories, the Oracle BI Server attempts to merge the filters automatically.

If an object is required for merging a particular filter such as a presentation column and isn' present, then that filter is considered invalid and doesn't appear in the merged repository. This rule doesn't apply to variables. If a variable is required for merging a particular filter, the Oracle BI Server ensures that the variable is retained in the merged repository.

Infer the Use Logical Column Property for Presentation Columns

Presentation columns have both a Name property and a Use Logical Column Name property.

In some cases, these properties can come into conflict. For example, the table shows a scenario where this situation could occur.

Repository Presentation Column Name Logical Column Name Use Logical Column Name

Original

Sales

GroupSales

No

Current

Sales

Sales

Yes

Modified

GroupSales

GroupSales

Yes

If the regular merge rules for the objects in the table are applied, the merged repository contains a presentation column called GroupSales and a logical column called Sales, with the Use Logical Column Name property set to Yes. This result is incorrect because the name of the presentation column is different from the name of the logical column.

To avoid this situation, the Oracle BI Server infers the value of the Use Logical Column Name property. Using the inference logic, the merged repository has a presentation column called GroupSales, a logical column called Sales, and the Use Logical Column Name property set to No.

Merge Aliases

During the full merge process, users aren't prompted to make decisions about aliases.

Aliases from the current and modified repositories are merged automatically.

In multiuser development merges, however, users are prompted to choose whether to keep aliases from the current repository, keep aliases from the modified repository, or merge choices to keep aliases from both repositories.

  • If object names change because of the merge process, then the previous names are added as aliases.

  • Any aliases that aren't associated with presentation objects are deleted.