| M | T | W | T | F | S | S |
|---|---|---|---|---|---|---|
| « Apr | ||||||
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 | |||
While the ADF that Oracle provides in JDEV is chock full of cool things, it seems that there are some things that could have been added to it. For example, you have two tables that are related by PK->FK relation that you want to represent in JDEV, the two tables use a trigger for generating the unique ids for the tables. JDEV handles this with a DBSequence, using temp Ids till the record is commited to the table, then it refreshed with the new permanent values.
You create your two entities and an association, linking them together in a parent child relationship. Things are great, the parent records can see the children records, and even the FKs are added into the newly created child records, when you call the create row method. However when you commit your changes, you notice that while the parent table has been updated and the primary key is now the one generated from the trigger, the child records did not update and still have the temp id stored on them, leaving you with orphaned records.
The new ADF guide covers this topic on how you can write the code to fix this, but before the guide was out, and back when JDev was 10.1.2, I wrote method to handle this, that I think is easy to use and works quite well. Lets take a look, the first thing is to go to your enitity objects code (yourEntityImpl.java). If you have not overridden the doDML method, click on the Source->Override from the JDEV Menu. You will get an initial code stub like below:
protected void doDML(int i, TransactionEvent TransactionEvent)
{
super.doDML(i, TransactionEvent);
}
If you are a forms developer and want to put this into perspective, anything you do before the call to the super method is a pre-trigger and anything after is a post-trigger. The first thing I do is relabel the i variable to something more understandable, I like to use operation.
Next we create the flow of the new code, here you can use if thens or the case statement, I prefer case here is the basic code so far:
protected void doDML(int operation, TransactionEvent TransactionEvent)
{
switch (operation)
{
case DML_UPDATE:
{
super.doDML(operation, TransactionEvent);
}break;
case DML_DELETE:
{
super.doDML(operation, TransactionEvent);
}break;
case DML_INSERT:
{
super.doDML(operation, TransactionEvent);
}break;
}
}
Now our Entity object has a handler that can handle all pre and post dml statment actions. The next step is to add in our code to handle the child records on a insert to be able to convert the FK Ids to the permanent one stored on the Parent Record. Here is what the new insert code looks like:
case DML_INSERT:
{
//////////////////////////////////////
// Pre Insert Actions //
/////////////////////////////////////
// Grab the child records before the update to the parent record.
RowIterator UpdateFilesIterator = getWorkFlowSteps_ASC();
//Call the super which saves the records.
super.doDML(operation, TransactionEvent);
//////////////////////////////////////
// Post Insert Actions //
/////////////////////////////////////
//If we did a insert of a work flow, and there are temp sequence numbers that need to be linked
//back to the parent record, this code gets the iterator and loops through the records updating the ids
//Create an instance of the child records.
WorkFlowStepsImpl updateFile;
//Loop throught he list of child records and update with new ID
while (UpdateFilesIterator.hasNext())
{
updateFile = (WorkFlowStepsImpl)UpdateFilesIterator.next();
updateFile.setAttribute(”WorkFlowId”, this.getWorkFlowId().getSequenceNumber());
}
}break;
Thats it, the records are saved and all is well. For record deletes you could work the same kind of logic, jsut placing it into the post delete action. I prefer to use the triggers on the database side to handle the cascading deletes.
Any questions or comments on this article please let me know.
September 28, 2006 at 2:07 pm
Thank you for posting with this solution. I struggled for a few months with this issue and eventually my team dropped Jdeveloper and ADF, one of the reasons being this issue.