Skip Headers
Oracle® Fusion Middleware Metadata Repository Builder's Guide for Oracle Business Intelligence Enterprise Edition
11g Release 1 (11.1.1)

Part Number E10540-06
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

D Merge Rules

This appendix provides information about the merge rules and behavior of the Oracle BI repository merge process.

When you use the Merge Repository Wizard in the Oracle BI Administration Tool, the patchrpd utility, or publish changes to the network in a multiuser development environment, sophisticated rules determine how objects are merged. Some decisions about merging objects are made automatically by the system, while other decisions appear as prompts in the Define Merge Strategy screen.

This appendix contains the following topics:

About the Merge Process

There are three types of Oracle BI repository merges:

The merge process typically involves three versions of an Oracle BI repository: the original repository, modified repository, and current repository. The original repository is the original unedited file (the parent repository), while the modified and current repository are the two changed files you want to merge. The current repository is the one currently open in the Administration Tool.

The original, modified, and current repository may mean different things, depending on your situation. For example:

Note that patch merge can be used with both of these situations. In a patch merge, you open the current file and select the original file, then generate the patch. To apply the patch, you open the modified file and select the original file, then apply the patch. See "Performing Patch Merges" for more information.

Merge Rules and Behavior for Full Merges

For full merges, the following general rules are applied:

In the Merge Repository Wizard, any decisions that require user input are displayed on the Define Merge Strategy screen. Figure D-1 shows the Define Merge Strategy screen.

Figure D-1 Define Merge Strategy Screen

Description of Figure D-1 follows
Description of "Figure D-1 Define Merge Strategy Screen"

Special Merge Algorithms for Logical Table Sources and Other Objects

In addition to the general rules governing how objects are merged and which situations require prompting, there are special rules for certain types of objects and situations.

This section contains the following topics:

Merging 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 execution 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 is not 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.

Example D-1 provides a detailed explanation of how object relationships are merged for application role objects.

Example D-1 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 is not 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 is not a member of the application role.

Table D-1 shows the merged result for different combinations of object relationships in the merging repositories.

Table D-1 Results for Merging Application Roles Based on Object Relationships

Original Repository Modified Repository Current Repository Result

M

M

M

NFoot 1 

M

M

Y

Y

M

M

N

N

M

Y

M

Y

MFoot 2 

Y

Y

ImpossibleFoot 3 

M

Y

N

Impossible

M

N

M

N

M

N

Y

Impossible

M

N

N

Impossible

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


Footnote 1 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.

Footnote 2 M in original for this case implies that either the user or application role is not present. The missing object added in both cannot be considered the same object.

Footnote 3 For two-way merge (also called full repository merge without a common parent), these results are not impossible, provided that the objects are equalized. Other results marked "Impossible" for three-way merge are similarly possible with two-way merge.

Merging 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.

Note that the deletion of a column is not considered to be a change in its mapping. If a column is not 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.

Merging 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 is not present, then that filter is considered invalid and does not appear in the merged repository. Note, however, that this rule does not 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.

Inferring 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, Table D-2 shows a scenario where this situation could occur.

Table D-2 Conflicting Presentation Column Name and Use Logical Column Name Properties

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 Table D-2 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. However, 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 this logic, the merged repository for the example in Table D-2 has a presentation column called GroupSales, a logical column called Sales, and a Use Logical Column Name property set to No.

Merging Aliases

During the full merge process, users are not 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.

Also note the following:

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

  • Any aliases that are not associated with presentation objects are deleted.

Merge Rules and Behavior for Multiuser Development Merges

The rules for multiuser development merges are very similar to the full merge rules, with the following important differences:

To change security settings or database features in a multiuser development environment, you must edit the master repository directly. To do this, remove the master repository from the multiuser development directory, edit it in offline mode, then move it back.

Merge Rules and Behavior for Patch Merges

The rules for patch merges are also similar to the full merge rules, except that the behavior for deleting objects is different. For example, if an object is deleted in the current repository, the default behavior for patch merges is to always ask the user whether the object should be discarded or retained. This is different from full merges, which often accept deletions from the current repository without prompting.

Using Patchrpd to Automate the Patch Process

You can use the -U and -V options in the patchrpd command-line utility to automate the patching process. The -U option enables the patching process to complete by accepting default decisions for conflicts, while the -V option enables you to specify an output file for recording all merge conflicts so that you can examine them and possibly take action later.

Follow these guidelines to use patchrpd to automate the patch process:

  • Apply patching automatically using default rules. Include the -U option in patchrpd to always apply the default decisions for conflicts. For example, if both repositories (current and modified) change the name of an object, the default decision is to keep the name in the modified repository, to avoid overwriting user customizations. If you do not include this parameter, patchrpd displays a warning and exits if a conflict is detected.

  • Record conflicts in an output decision file. Include the -V option to cause patchrpd to generate a decision file that shows all the conflicts from the merge. The decision file lists the decisions that would have been displayed in the Define Merge Strategy screen of the Merge Wizard if the merge had been performed in the Administration Tool. The decision file provides a record of all items that can be influenced by user input.

  • Modify the decision file to change the result. After you run patchrpd, there are two ways to make changes to the resulting repository:

    • You can use the Load Decision File button in the Define Merge Strategy screen of the Merge Wizard to load the merge decisions, and then change the decisions if needed. You can then complete the merge in the Administration Tool. Alternatively, you can save the modified decision file using the Save Decisions to File button, and then re-run patchrpd with the decision file as an input using the -D option to reapply the patch with the new decisions.

    • You can edit the decision file by hand, and then re-run patchrpd with the decision file as an input using the -D option to reapply the patch with the new decisions.

See "Using patchrpd to Apply a Patch" for full information about patchrpd usage and syntax.