On 2/3/19 7:54 AM, Simon Van Casteren wrote:
About your first comment,
Yes I have the same code habit of first running validations and then
doing the actual work. As long as stuff stays kind of simple that is
manageable. But a place where this has caused some serious bugs was in
my import page. So I have a function that runs validations and then
makes the resource in the database. Now, my import page makes many of
these at once, based on a CSV file format (see one of my previous
questions). However when one fails, I'd like the whole import to fail.
A complete rollback operation would make this much easier and less
error-prone since I now have to delete all the previous saved resource
when one resource fails to save. It was more of a question on how to
do it though, since providing an explicit rollback is probably more
dangerous than it's worth.
Right. This part sounds doable by splitting your import functionality
into separate validation and database insertion. It sounds like a small
drag, but at least it only locally affects your use case.
One example of a pain arising from general database rollback is: imagine
a nicely encapsulated function that allocates a message-passing channel,
stashes it in an appropriate database table, and returns it to the
caller (perhaps declared as an abstract type, so the caller doesn't even
know a channel is involved). The caller uses the rollback function you
asked for, but the caller also hangs onto and uses the channel. Now we
have a scary ability to break application-wide invariants: rollback is,
in effect, a way to mess with "private fields" of library modules!
_______________________________________________
Ur mailing list
Ur@impredicative.com
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
