[Ur] Explicitly asking for a sql rollback

[Adam Chlipala]

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!