Sure. Let's say you have an Emp entity object and an EmpView view object based on the familiar EMP table.
Furthermore, let's say for the sake of argument that in our application, an employee is considered "deleted" if he has a value of -1 for his COMM column.
There are two steps to implementing the desired behavior:
- Modify our EmpView view object ignore "deleted" employees in the query.
- Modify our Emp entity object to change its default behavior when an instance is removed.
Step 1 is easily handled by adding a (additional?) custom WHERE clause to the EmpView of:
COMM IS NOT NULL OR COMM <> -1
This will cause "deleted" employees to not appear in the view.
Step 2 is easily handled by overriding two base framework methods in your entity object class, EmpImpl.java.
protected void doDML(int operation, TransactionEvent e) {
/* If we're being asked to perform a delete, do an update instead. */
super.doDML(operation == DML_DELETE ? DML_UPDATE : operation,e);
}
public void remove() {
setComm(new Number(-1)); /* Set Comm to (-1) as a deleted flag. */
super.remove();
}
The overridden remove() method sets the "Comm" attribute to the value -1 as a deleted flag, then calls the superclass' implementation of the remove() method to do the default behavior of adding that row to the list of rows that BC4J considered deleted and which will be processed as deletes the next time the transaction is posted or committed.
The overidden doDML() method slightly changes the default framework behavior so that when BC4J asks the entity object instance to perform a delete DML operation, instead it asks the superclass' doDML() method to perform an update instead.
That should do it. Try it out and use the BC4J Tester to verify that it works.
3:49:45 PM 
|
