[Ur] Explicitly asking for a sql rollback

Simon Van Casteren simon.van.casteren at gmail.com
Sun Feb 3 11:25:01 EST 2019


Yeah I figured that would cause more problems than it would solve but still
glad I asked. I might rewrite my import like you said. It is a better way
of doing things.

Thanks!

On Sun, Feb 3, 2019, 3:14 PM Adam Chlipala <adamc at csail.mit.edu wrote:

> 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 at impredicative.com
> http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.impredicative.com/pipermail/ur/attachments/20190203/cf4ef138/attachment.html>


More information about the Ur mailing list