Reputation: 3
is there a way to rollback a specific change. I have a button that creates a row in two different tables. I want the changes in one of the tables to be rolled back before the committing so that only the second table is committed. How would this be done? Running normal rollback rollbacks both table iterators.
Ive been trying different methods and nothing is working, Please help before I go insane.
Upvotes: 0
Views: 851
Reputation: 86
find out the corresponding 'VO' row which you want to rollback .
#1. row.setNewRowState(Row.STATUS_INITIALIZED) ;
or
#2. row.revertRow() ;
or
#3. row.remove() ;
Upvotes: 1
Reputation: 105
The closest thing to rolling back a row would probably be calling refresh on the view row with the appropriate parameters, something like this:
//Obtain app module
DCBindingContainer dcb = (DCBindingContainer) BindingContext.getCurrent().getBindingsEntry();
ApplicationModuleImpl am = (ApplicationModuleImpl) dcb.getDataControl().getDataProvider();
//Get your view
ViewObjectImpl vo = am.getMyView1;
ViewRowImpl row = vo.getCurrentRow(); //alternately use vo.findByKey to lookup a row or simply iterate through every row if dataset is sufficiently small
//rollback the row
row.refresh(Row.REFRESH_REMOVE_NEW_ROWS | Row.REFRESH_UNDO_CHANGES | Row.REFRESH_CONTAINEES);//review modes for ideal combination for use case
Note that rather than a refresh, a row.remove()
would probably be sufficient for what it sounds like you are trying to do. In any case, you will need to keep track of the rows you do not want to commit.
While this solution would work, it does not sound ideal for your use case. If you never commit data in the other table, there is no reason to link it to a database table. I would probably do something like one of the following instead:
If the fields are the same in both tables (or similar) and it will be an all-at-once action, create a transient attribute on the ADF view object to denote whether or not the row is approved. Use view criteria on different instances of the view object (add to your application module twice) to display/process the rows you want. Remove not approved rows prior to committing.
If the fields needed are too different or you want to be able to handle one row at a time, make you history view object a programmatic view object with transient attributes, rather than basing it on the table/Entity. When a row is approved remove it from your history view and add it to your approved view.
Upvotes: 0