Its always a bit confusing - what is actually the difference between Initialized and New mode for created rows in ADF BC. I have found good information in ADF Developer Guide for this - 27.4.5 What You May Need to Know About Create and CreateInsert. In short - when you create new row, it gets status New. If there is requirement to deregister created (but not yet inserted into DB) from pending changes list - you can set Initialized status for such row. It will keep Initialized status, until user will change attribute value.
I have created small sample application to test this behavior - NewInitializedRowADF.zip. This application implementes two methods in AM implementation class:
These two methods are almost the same, except - row.setNewRowState(Row.STATUS_INITIALIZED) statement in the first method. This methods assigns newly created row with Initialized status. Both methods are invoked from ADF UI. Sample application is based on Employees table from HR schema. This table contains number of required attributes - for the test purpose, I have set default values for each of required attributes (this allows to avoid validation errors).
Test is really simple - calling one method and then checking if pending changes exist, same done for the second method.
Firstly I was testing the method where row is created with the default status New. Pending changes are reported:
Next - method with row.setNewRowState(Row.STATUS_INITIALIZED) statement was tested. No pending changes detected for inserted row:
Setting row with Initialized status is useful, when we want to delay pending changes check. For example, when new row is created with default values from PL/SQL functions - we don't want to consider it as candidate for pending changes in ADF, until user types value by himself.
I have created small sample application to test this behavior - NewInitializedRowADF.zip. This application implementes two methods in AM implementation class:
These two methods are almost the same, except - row.setNewRowState(Row.STATUS_INITIALIZED) statement in the first method. This methods assigns newly created row with Initialized status. Both methods are invoked from ADF UI. Sample application is based on Employees table from HR schema. This table contains number of required attributes - for the test purpose, I have set default values for each of required attributes (this allows to avoid validation errors).
Test is really simple - calling one method and then checking if pending changes exist, same done for the second method.
Firstly I was testing the method where row is created with the default status New. Pending changes are reported:
Next - method with row.setNewRowState(Row.STATUS_INITIALIZED) statement was tested. No pending changes detected for inserted row:
Setting row with Initialized status is useful, when we want to delay pending changes check. For example, when new row is created with default values from PL/SQL functions - we don't want to consider it as candidate for pending changes in ADF, until user types value by himself.
2 comments:
Hi Andrejus,
it appears I have run into a deadlock maybe you or someone reading this can help me figure out. I have a 'create' operation for Master-Detail relationship. The association between the entities involved has 'Composition Association' selected. When 'create' is invoked master and detail entities need to be set up with some default values. Now the thing is, when I call setNewRowState(Row.STATUS_INITIALIZED) before inserting the row into VO I get 'JBO-25030: Detail entity xx with row key oracle.jbo.Key[yy] cannot find or invalidate its owning entity.' which is an expected behaviour according to the doc . When trying to set setNewRowState(Row.STATUS_INITIALIZED) at the end of the method the entities seem not to get removed from transaction and validation managers (The create popup cannot be closed bacause of pending changes).
Any help much appreciated.
Hi Andrejus,
Download link is broken.
Post a Comment