This content has been marked as final. Show 11 replies
Repost - To clear up some confusion: Both views are instances of DeptView.
Repost - Can someone from Oracle please comment - This opposes the manual.
The stack trace makes it clear that you're calling commit() and that commit performs validation on any entities in the entity cache.
In what way does the validation of "dirty" entities in the entity cache at commit time conflict with the manual or the JavaDoc? Can you clarify?
Creating a row in a VO that is related to an EO immediately creates the underlying entity in the entity cache as soon as its primary key attribute is filled in.
If you want to mark a row as being "throw-away", then you can either:
1. Call remove() on that new row, or
2. Call setNewRowState(Row.STATUS_INITIALIZED)
and it will not be validated since it won't really "be there" until someone sets some attributes on it again.
My problem is not with any of your comments previously, but with the fact that the newly created row is automatically inserted into other Views/RowSets that feature the same EOs.
Normally, to create a row in a View, you have to
2. Set the key attributes and
Why is this routine ignored for other views accessing/using the same EO cache.
To put it another way.
DeptViewImpl deptView1 = getDeptView1();
DeptViewImpl deptView2 = getDeptView2();
This means that i have 2 Instances of DeptView.
Creating a row through deptView1 (createRow()) will not insert the row into deptView1's default RowSet until the keys have been set and the row inserted into the view(insertRow(newDeptRow)). Only then will it appear on the particular view's default RowSet.
The problem here is that the row automatically appears in deptView2. Why all the fuss in deptView1 when all this is bypassed in deptView2? It appears that a new EO Row is imediately added to all the participating views irrespective of the entity status.
Why the steps above for the programatic entry and the exact opposite for the framework entry?
By the way - the error occured trying to print the content of the second view which was populated with the row representation of the incomplete EO created through the first view - Not on the commit.
My mistake - I was trying to validate a TAR on a older version of BC4J that gave the error above.
The test on the older version gave the exception on accessing the second view. The latest release of BC4J throws the exception, but as Steven rightly said, it is on the commit - which is absolutely correct.
The reflecting of newly created entity objects in other view objects row sets is part of the "Viewlink Consistency" feature. If this is set to "on" for a view object, it tries to keep itself up to date with newly-created entities that other views (related to the same entity object) have created.
I just noticed this new behaviour in 9.0.4 (it was not true in 9.0.3.x, including x=4). Btw, the "viewlink consistency" name is not a very good choice, since there is no view link involved...
The trouble is that the new row is created in the second view using the create() method in the view row. And this is not acceptable when access rights are specified on the VOs (see TAR 3874809.999).
While removing the viewlink consistency on the AM is solving the problem, this is not an alternative in the "real-world"...
IMHO, the new row should be added to the second VO, according to the consistency level set, but without interacting with the user. As if the row was in the database...
As a workaround, which is the proper place to change the "Viewlink Consistency" property of a VO?
Can you clarify in what way the viewlink consistency mechanism is involved in interacting with the user? The create() method on a viewobject fires when a view row is created in any rowset for that view object (by the user, or programmatically).
The mechanism, named this way because it initially only worked for detail collections via a view link, causes new view rows to be automatically created in rowsets from view objects marked as viewlink consistent.
You can control the behavior using the setAssociationConsistent(boolean) method on any rowset. In 9.0.4, by default the jbo.viewlink.consistent property is set to the value "DEFAULT" which has the behavior of making view objects with a single entity insert participant (one EO usage marked as non-reference) work in viewlink consistent mode, and any VO's with 2 or more insert participants, work in viewlink inconsistent mode.
You can globally change the default to jbo.viewlink.consistent=false in the configuration to have the 184.108.40.206 and earlier behavior.
Well, my statement was not very "proper". The fact is that we used your hint from http://radio.weblogs.com/0118231/stories/2003/01/18/implementingConditionalInsertUpdateAndDeleteAllowsForViewObjects.html to manage the access rights on operations. So, finally, the fact of getting in ViewRowImpl.create() is user-related (for our application, at least).
It seems as the only workaround we have available is to "break" the view consistency, which is not a very "clean" way out. Let me explain.
A module in our application has DEPT as master and EMP, JOB as details. But, in the EMP view, the user is able to create also JOB rows (entity rows, I mean). The JOB view instead, it's only for display. I know, it's a bit strange, but in the context of the application, it looks much more natural.
When a new row is created in EMP (and a new JOB is created there), the create() method is triggered for JOB view, which, of course, will raise an exception (since there are no insert rights on that view). But the user only performed permitted operations.
Do you think there is a "clean" solution to this kind of problem?