Re^2: Poor man's transaction construct

Ah yes, thank you. That saves me a level of indentation.

As for rollback in eval(), I want to make sure that when a rollback step dies, the next step is still executed, so that "cleanup is robust". I need to dwell some more on whether this is actually a good thing or bad.

Comment on Re^2: Poor man's transaction construct

Replies are listed 'Best First'.
Re^3: Poor man's transaction construct by aquarium (Curate) on Nov 24, 2010 at 22:01 UTC
the rollback should die if a step dies..or you will quite possibly be undoing things that cannot be undone if the prior (undo) step failed. automatically undoing with commands like "rm -r -f dirname" should not (in my opinion) be ever run automatically, and as part of an undo sequence even more dangerous. i think it is a bit ambitious to be constructing code to automatically undo other code. the original (non-undo) code fails for some unknown reason, which was not catered for in the code...so how does one then produce undo code that should be even more robust? also the entire undo sequence does not need to follow exactly every step of normal run code. if the normal code creates a db, then creates tables, and then populates those..the undo should be merely a drop db. so if you absolutely must write this code, by grouping certain steps linked to a single undo step, it will be more robust by virtue of fewer undo steps code to run. the hardest line to type correctly is: stty erase ^H	[reply]
Re^3: Poor man's transaction construct by ikegami (Patriarch) on Nov 24, 2010 at 16:34 UTC
As for rollback in eval(), You're talking about the eval in the rollback code. I was talking about the other eval.	[reply]