Timeline for better method to revert state if failure occures during add/delete
Current License: CC BY-SA 3.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 18, 2013 at 12:50 | comment | added | Victor | @dsollen cheers, glad it appears to be working out for you in the end. | |
| May 16, 2013 at 14:31 | comment | added | dsollen | You were right ultimately. The mutable structure just ended up with too many 'smells', I gave up and made it all immutable; but with a model that still automatically keeps track of children/parent relationships via hashMaps in a generic manner (so I can still add a child to a parent quickly, because the parent doesn't know the child directly; it only knows it's children via a call to the model. Once I did this I can almost do what you suggested for rollback. I need to actually add things to my model as I go to keep getChildren working. I can record every add/remove and revert if needed. | |
| May 16, 2013 at 14:27 | vote | accept | dsollen | ||
| May 16, 2013 at 14:27 | vote | accept | dsollen | ||
| May 16, 2013 at 14:27 | |||||
| May 1, 2013 at 12:39 | comment | added | Victor | @dsollen in that case, perhaps you could aggregate a rollback lambda using the command pattern? | |
| Apr 30, 2013 at 18:33 | comment | added | dsollen | I wanted to do it this way. but I have many children being created at the bottome level of the tree. adding one means replacing it's parent, and it's parent's parent etc etc. it would grow CPU intensive to make some changes this way. | |
| Apr 30, 2013 at 13:09 | comment | added | Neil | +1. This is the approach I use, and it's probably saved me countless hours too. | |
| Apr 30, 2013 at 12:50 | history | answered | Victor | CC BY-SA 3.0 |