Before 9.0.3.3, the ViewLink Consistency feature only worked for view objects having a single updateable entity usage which happened to be details of an active ViewLink. Customers understandably asked for a more useful behavior in which view objects at any level (details or not) would be kept consistent with new rows inserted through any other view object sharing the same entity usages. The 9.0.3.3 release of BC4J added support for this customer request so that ViewLink Consistency works for any view object having a single updateable entity.
Combining the ViewLink Consistency feature with view objects that have two-or-more updateable entity usages currently can produce unexpected results because the framework does not yet provide enough user-pluggable API's to control how the multiple new entity parts in these viewlink-consistency-created view row should be handled.
For example, imagine a view object named "InsertNewDeptAndFirstEmp" with updateable entity usages for both Emp and Dept entity objects. Now consider two other view objects named "AllEmployees" and "AllDepartments" that each has a single updateable entity usage for the Emp and Dept entities, respectively. If you have view link consistency mode turned on for both of these views, then the following will happen in 9.0.3.3:
- If you insert a new department and new employee in the
InsertNewDeptAndFirstEmp view by creating a new row there, then a new row will be automatically added to the AllEmployees view to reflect that new employee and a new row will be added to the AllDepartments view to reflect that new deparment.
- If you insert a new employee in the
AllEmployees view, a new row will be created in the InsertNewDeptAndFirstEmp view (having the entity part corresponding to the newly inserted employee, and a new Dept entity for its Dept entity part.)
- If you insert a new employee in the
AllDepartments view, a new row will be created in the InsertNewDeptAndFirstEmp view (having the entity part corresponding to the newly inserted department, and a new Emp entity for its Emp entity part.)
There's a very good chance that behaviors number 2 and 3 above are not really what you want in your application. Until we add more fine-grained control in our framework API's for letting the developer decide how the multiple underlying entity parts of each viewlink-consistency-created view row should be handled in an application-specific manner, it's recommended to use view link consistency only for view objects with a single updateable entity usage.
The default value (of 'DEFAULT') for the BC4J configuration property jbo.viewlink.consistent property guarantees that the framework will treat:
- View objects with a single updateable entity usage as viewlink consistent, and
- View objects with two-or-more updateable entity usages as NOT viewlink consistent
However, actually getting BC4J 9.0.3.3 to use this default setting is a little more complicated than you might expect due to the fact that we wanted to guarantee that upon upgrading existing applications to 9.0.3.3 that the existing pre-9.0.3.3 behavior would be maintained for backward compatibility.
In 9.0.3.3 there is an entry in the ./oracle/jbo/server/jboserver.properties file (which is archived into the ./BC4J/lib/bc4jmt.jar file) that reads:
# view link consistency setting
# The default in 903 is false.
# This flag is set to 'default' in 904 to imply that
# consistency is turned on for VOs with one updateable Entities.
## For the rest, an app developer has to make this call.
jbo.viewlink.consistent = false
If the jbo.viewlink.consistent property is left at its default value of 'DEFAULT' in the configuration, it is not recorded in the bc4j.xcfg file since the runtime framework knows the value of the default. However, BC4J uses a layered scheme to determine the value of each of its many configuration parameters at runtime which follows the following precedence rules. The first location in the ordered list below at which a given configuration parameter is found will define its value at runtime:
- Client environment (set programmatically or driven by contents of named configuration in
bc4j.xcfg file)
- Applet tags (if applicable)
-D flags (appear in System.properties)
BC4J.properties file in current working directory of Java VM
/oracle/jbo/BC4J.properties resource in the runtime class path
/oracle/jbo/server/jboserver.properties resource (by default found inside bc4jmt.jar)
/oracle/jbo/common/Diagnostic.properties resource (by default found inside bc4jmt.jar)
- System defined default as a fallback.
Due to this layered scheme, since jbo.viewlink.consistent will be omitted from the bc4j.xcfg file when it has its default value of 'DEFAULT' -- and thus won't be part of the "client environment" hashtable at application module instantiation time -- BC4J will find the jbo.viewlink.consistent property in the jboserver.properties file inside bc4jmt.jar and so it will take on the value of false. This was done to guarantee that 9.0.3.X clients upgrading to 9.0.3.3 did not undergo a change in runtime behavior in this regard by simply upgrading.
So, to make sure that you really get the new 9.0.3.3/9.0.4 default view-link consistent behavior for single-updateable-entity view objects, you need to do one of the following (they all will have the same effect):
- Add the
-Djbo.viewlink.consistent=DEFAULT to your Java VM command line
- Add an
/oracle/jbo/BC4J.properties file to the runtime class path containing a line that reads:
jbo.viewlink.consistent = DEFAULT
- Extract
oracle/jbo/server/jboserver.properties file from bc4jmt.jar, update it to comment out the line:
jbo.viewlink.consistent = false
and use 'jar uvf' to update the bc4jmt.jar archive file with the modified jboserver.properties file (with the appropriate oracle/jbo/server directory structure preserved in the archive!)
1:28:09 PM 
|
