| Oracle® Fusion Middleware Metadata Repository Builder's Guide for Oracle Business Intelligence Enterprise Edition 11g Release 1 (11.1.1) Part Number E10540-01 |
|
|
View PDF |
| Oracle® Fusion Middleware Metadata Repository Builder's Guide for Oracle Business Intelligence Enterprise Edition 11g Release 1 (11.1.1) Part Number E10540-01 |
|
|
View PDF |
When you use the Merge Repository Wizard in the Administration Tool, sophisticated rules determine how objects are merged. Some decisions about merging objects are made automatically by the wizard, while other decisions appear as prompts in the Define Merge Strategy screen. This appendix describes some of the merge rules and behavior of the Merge Repository Wizard.
There are three types of merges:
Full merges are typically 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" for more information.
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" for more information.
Multiuser development merges are used when you are checking in projects using a multiuser development environment. See "About the Multiuser Development Merge Process" for more information.
This appendix contains the following topics:
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:
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 customizations you made to the original file.
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.
Regardless of which merge scenario you want to perform, and regardless of the merge type (full, patch, or multiuser development merge), 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.
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.
Some other rules are dependent on the type of merge you want to perform. For example, if you are performing a patch merge to upgrade a repository, you want to retain the security settings and database feature table changes in your customized (modified) repository. If you are performing a multiuser development (MUD) merge, however, you do not want to retain security settings and database feature table changes, to prevent developers from overwriting passwords and other important objects in the master repository. Because of this, changes to security settings and database features are not retained when you perform a MUD 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.
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:
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 |
|
|
M |
M |
Y |
Y |
|
M |
M |
N |
N |
|
M |
Y |
M |
Y |
|
M |
Y |
Y |
ImpossibleFoot 2 |
|
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 implies that either the user or application role is not present. The missing object added in both cannot be considered the same object.
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.
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.
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.
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.
|
 Copyright © 2010, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
