We use Steve Muench example for restoring current row after rollback is executed.
http://blogs.oracle.com/smuenchadf/examples/
http://otn.oracle.com/products/jdev/tips/muench/restorecurrencyonrollback/RestoreCurrentRowAfterRollback.zip
It was working fine until we started using Range Paging on view objects.
In view objects with range paging, if you select a row in the first page of range then rollback keeps the same row.
But if you select a row that is not on the first page of range, rollback gets you to the first row or throw a null pointer exception.
Reviewing the code of afterRollback method
public void afterRollback(TransactionEvent TransactionEvent) {
super.afterRollback(TransactionEvent);
if (currentRowKey != null) {
Key k = new Key(currentRowKey.getAttributeValues());
Row[] found = findByKey(k, 1);
executeQuery();
…
I noticed that it was calling executeQuery() method. I moved that call tbefore the findByKey method, and then rollback restores the current row after rollback even for view objects with Range Paging :
public void afterRollback(TransactionEvent TransactionEvent) {
super.afterRollback(TransactionEvent);
if (currentRowKey != null) {
executeQuery();
Key k = new Key(currentRowKey.getAttributeValues());
Row[] found = findByKey(k, 1);
…
Is this magic?
Do I miss something? Or it should be like that?
test case:
http://adfbugs.googlecode.com/files/TestRollbackRow.zip
ADF is like a wife. At first you are so passioned about her and you find her incredible.. Then, you start finding flaws.. Eventually you are so dissapointed with her that you forgot why you liked her in the beginning....
ReplyDeleteWell it's actually more like a bad wife.
ReplyDeleteYou start with a thought better something than nothing, flaws are everywhere. But with time you start to learn how to avoid her bad temper, and life is easier. And at the end you are old and nobody likes you, so you stick with her. But there are so many beautiful women out there so you keep on asking yourself: Why? Was I really that desperate? :)
Ne volim te, nisam te nikad volio,
ReplyDeletena tvoje omiljeno pitanje evo ti odgovor,
bio sam mlad i totalno zagorio,
tako je valjda sve to krenulo...
FYI, I tried moving the executeQuery() before the new Key() line as described by Milkbird. I ended up with odd behavior (tested without range paging). If you edit a row that is not in the first range, then perform a rollback, then scroll back in the af:table to the first range, you will notice that the row you edited is now located in the position rangeSize+1. If you scroll down to where the row should be, its not there. Very odd. If I put the executeQuery() back to where Steve had it originally, this issue did not occur. I was hoping for solution that worked either way (range paging on/off). I did not try this solution with range paging on.
ReplyDeleteDimitrios, Milos, you made my day xD
ReplyDeleteSo true.