[SOLVED] ADF BC : View Object "second level" Entity reference issue

Question

hi
If I insert a row in a View Object that uses "two levels" of Entity references, the attributes of the Entity on the "second level" don't get a value.
Consider these tables:
MY_ROW (MY_ROW_ID, MY_ROW_STUFF, MY_ROW_LU1_ID)
MY_ROW_LU1 (MY_ROW_LU1_ID, MY_ROW_LU1_STUFF, MY_ROW_LU1_LU1_ID)
MY_ROW_LU1_LU1 (MY_ROW_LU1_LU1_ID, MY_ROW_LU1_LU1_STUFF)
Where MY_ROW.MY_ROW_LU1_ID is a "look-up" in MY_ROW_LU1 and MY_ROW_LU1.MY_ROW_LU1_LU1_ID is a "second level look-up" in MY_ROW_LU1_LU1.
I created default Entities and Associations on these tables and a View Object that uses all 3 Entities (MyRow as Updatable, MyRowLu1 and MyRowLu1Lu1 as Reference).
See example code in
http://verveja.footsteps.be/~verveja/files/oracle/ViewObjectEntityReferenceIssue-v0.03.zip
(contains no Java code, all out-of-the-box ADF BC)
problem scenario:
If run the MyRowService Application Module in the Oracle Business Component Browser and "open" the MyRowViewAll View Object instance, I get the rows and their related "look-up values".
If I click the "Insert a new record" button and fill out values for MyRowId, MyRowStuf and MyRowLu1IdEntity, I only get "look-up" values for the "first level". While the "second level" stays empty.
For example, a MyRowLu1IdEntity of "2003" gives a MyRowLu1Stuff value of "2003 stuff", but no value in MyRowLu1Lu1Stuff.
What am I doing wrong? What should I change to also get a value in the "second level" MyRowLu1Lu1Stuff attribute?
many thanks
Jan Vervecken

Answer 1

Jan,
If you create a view object on Emp and Dept, with Dept as a reference entity, you might choose to build the view object to only include the:
Emp.Empno (required, since it's the PK of Emp entity usage)
Emp.Ename (included since you want to show the ename)
Dept.Deptno (required, since it's the PK of the Dept entity usage)
Dept.Dname (included since you want to show the dname)
The wizard enforces the inclusion of the required attributes above.
When you run this view object, a join is performed and you see the reference data.
Now, if you want to allow the user to UPDATE the reference data, you need to add one more attribute to the list of attributes:
Emp.Empno
Emp.Ename
Emp.Deptno (To allow user to change Deptno employee belongs to)Dept.Deptno
Dept.Dname
At this point, not only is the join performed for you, but the ADF BC reference mechanism reacts to any modification of the Emp.Deptno attribute, correctly showing the reference information for that new foreign-key-referenced department (even before commiting and requerying, at which time the SQL join would pickup that correct, related information).
The "second level" problem you describe in this thread is simply the same issue described here as a master/first-level-detail situation, taken to its logical next step. If you want the end-user to be able to change the second-level detail to which the first-level-detail is associated, you need to include the first-level-detail's foreign key attributes in the view object's select list. Otherwise, there is no foreign key attribute whose value-change event the framework can react to in order to coordinate the related reference data in the row.
I've blogged a link to a working example of a four-level reference information view object here:
http://radio.weblogs.com/0118231/2007/05/09.html#a818
based on the HR schema.