Thursday, August 7, 2014

ADF PASSIVATION/ACTIVATION - previously selected row gets populated in detail ViewObject, even it doesn't belong to Master ViewObject

JDeveloper 11.1.1.7

Updateable detail view object with viewCriteria applied at application module level, populates previously selected row from another parent, this only happens when running the application while application module pool set off to force Passivation/Activation, and the detailed viewObject have a viewCriteria applied to it.

This is reported to Oracle under (Bug 19203478 - ADF PASSIVATION/ACTIVATION - PREVIOUSLY SELECTED ROW GETS POPULATED).

A sample ADF application is attached here (EmplDeptPassivate.zip)

To reproduce this:
- Create new ADF application with default Model project and view Controller
- Database connection points to HR schema
- Create Business components from tables, only select Employee and Department tables, don't add the view Objects to application module.
- Add DepartmentView as master vo then EmployeesView as detail for departments.
- Create view criteria("EmployeesViewCriteria") in EmployeesView where ManagerId=102
- Return back to application module -> data model and edit EmployeeView1 and apply the view criteria.
- Set Application Module pool off, and disconnect upon release on
- Create a view criteria in DepartmentView to search for department name used in search page only.
- Create two ADF pages in bounded or unbound Taskflow
- First page drag DepartmentViewCriteria and add Query with Table, select single selection, filtering and sorting
- Second page drag EmployeeView1 as table, select single selection, filtering and sorting.
- Add navigation links between the two pages, convert department id outputText to link and set the action to the detail page(Employee page)
- Add back and commit buttons to the Employee page
- back should navigate back to search Departments page
- commit because we will change one record at first time
- run the Department Search page
- Search and select the first department with id=10
- Change the manager ID to 102 and save
- Back
- navigate to Department id=60 IT or any other department it shows the selected record from department id=10
- rerun the application many times as you want with changing the manager id to 102 this time because its one time change only, problem will still persists
- enable application module pool on again, problem disappears.

As a workaround to solve this problem, just change the ViewObject that have the ViewCriteria to expert mode VoilĂ .

Another cause of error (JBO-25014: Another user has changed the row with primary key oracle.jbo.Key[x])

Note this bug happens when using JDeveloper 11.1.1.7, I didn't test it on 11g release 2 versions or 12c, but I assume it might happens as well.

Apparently there is another cause of "JBO-25014 user changed primary key error" other than the ones discussed in Chris Muir post (The_case_of_the_phantom) or Jobinesh post (what-you-may-need-to-know-about-nested). This is related when Passivation/Activation occur while the user is changing a record on Master view object that uses an entity and this entity has a reference usage in the detailed view object.

You can test this by setting Application Module pool off. Assuming the user want to change the hire date of the employee in the master form for specific employee, at the same time the hire date is being referenced in the detail job description table showing readOnly hire date field next to the employee job description (Using Entity reference of-course).

When the user changes the field and the field has autosubmit set on, Passivation/Activation process will happen at the stage, then the user hit the save/commit button, ADF will do another Passivation/Activation process. It will activate the (VOs) including field values (New submitted along with Original) as first step of execution, thus while trying to activate the DoDML method will fail and throw a JBO-25014 error. This because the system will go and check the Entity state if it Synced with the database table to find any mismatch in field values.

It will compare the original field value against the database value, the original field value which is Passivated was overwritten from the detail Entity reference when the first Passivation/Activation happens, thus comparing two different value ( which contains the new data after the first Passivation/Activation process) with the original database value which is not changed or touched at all, and then throwing JBO-25014 exception.

This is a bug in ADF that only happens when Passivation/Activation happens in the system and there is a circular dependency between Entities used in the same page. The workaround is use a inline sub-query inside the detail ViewObject rather than using Entity reference specially when you know that you will build a screen that will have that field 1- editable, 2- referenced at the same time in the same screen, and 3- there is a possibility that Passivation/Activation will occur at some stage.

I will address anther bugs in Passivation/Activation mechanism in the following posts that I already submitted SRs for, at Oracle Support.