When you use the Merge Repository Wizard in the 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:
Oracle BI repository has three types of merges.
Full merges, sometimes called upgrade merges, are used during development processes, when there are two different repositories that need to be merged. The Administration Tool provides a three-way merge feature that lets you merge two repositories that have both been derived from a third, original repository. Full merges can also be used to import objects from one repository into another, see Performing Full Repository Merges.
Patch merges are used when you are applying the differential between two versions of the same repository. For example, you might want to use a patch merge to apply changes from the development version of a repository to your production repository, or to upgrade your Oracle BI Applications repository, see Performing Patch Merges.
Multiuser development merges are used when you are publishing changes to projects using a multiuser development environment, see About the Multiuser Development Merge Process.
The merge process involves three versions of an Oracle Business Intelligence repository: the original repository, modified repository, and current repository. The original repository is the original unmodified 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:
In a development-to-production scenario, you have an original parent file, a current file that contains the latest development changes, and a modified file that is the deployed copy of the original file.
In an Oracle BI Applications repository upgrade scenario, the current file is the latest version of the repository shipped by Oracle, and the original file is the original repository shipped by Oracle. The modified file is the file that contains the changes you made to the original file.
You can use patch merge 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.
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 have the minimum set of objects necessary to service your queries. During a merge, it is possible that objects were introduced by the current repository that are not 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 are not kept. 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 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 are not 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.
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:
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.
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.
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 is not present. The missing object added in both cannot 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 |
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 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.
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. 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.
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.
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.
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.
The rules for multiuser development merges are very similar to the full merge rules, with important differences.
Changes to security settings are not retained when you perform a MUD merge to prevent developers from overwriting passwords and other important objects in the master repository.
The database and connection pool properties in the master repository take precedence over the same properties on the developer's computer. This precedence are applied without a prompt during a multiuser development merge.
Inserts (created objects) are applied automatically. Because a subset of the master repository is being used as the original repository, most objects in the master repository appear to be new. This would result in many unnecessary prompts that the developer would have to manually approve. Therefore, new objects are created without a prompt during a multiuser development merge.
Conflicts that are not inserts but are resolved because of the automatic inserts are applied without a prompt during a multiuser development merge.
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.
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.
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.
Follow these guidelines to set up patchrpd to match the Administration Tool's merge functionality:
Administration Tool's full merge - Use the -A option, apply changes on the whole repository, and -M option, use upgrade mode.
Administration Tool's patch merge with the "use subset patching" option selected - Do not include the -M option. Excluding the -M option means that the default merge mode is set to patch.
Administration Tool's patch merge with the "use subset patching" option not selected - Use the -A option and do not include the -M option. Excluding the -M option means that the default merge mode is set to patch.