[Ur] Explicitly asking for a sql rollback

[Simon Van Casteren]

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.

On the second part,

Yes, the test harness could do that, and it's kind of what I'm doing now.
It's OK, but it's a bit slower and a bit more heavy handed. I'm ok with it
though, I would still use the rolback operation here as well though, if it
was available. It's not necessary though.

Simon

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

> On 2/3/19 5:24 AM, Simon Van Casteren wrote:
>
> I'm wondering if there is a way to explicitly ask for a sql rollback. I
> think the only way you can now trigger a rollback would be by calling the
> "error" function and providing an xbody.
>
> I have two use cases for which I think an explicit rollback mechanism (not
> sure how that would look like) would be handy. My main use case is rolling
> back everything when a validation is not ok. I don't use the "error"
> function because I can't return structured error messages. When I save some
> form with 5 fields, I mostly return an error object with the same 5 fields,
> so I can provide precise feedback to the user. Having to clean up all my
> sql work is huge drag and a source of subtle bugs.
>
> Let me check that I understand: you want a transaction to return a
> structured value that will actually be processed further by legit code, say
> the client-side code that has called your server-side RPC?  However, you
> will undo all database effects, so that the transaction that leaked a
> result back to legit code that is now "apocryphal" in terms of database
> effects?  Wouldn't it be nicer to maintain a data structure in your RPC
> handler that batches all database updates until you are sure you really
> want to run them?  I wouldn't expect to see it complicate the code much.
> In fact, I would naturally write database updates *after* all validation,
> so that no special code complication is needed.
>
> My second use case is testing with the database. I know some people frown
> upon incorporating the database into your tests, but I think that's silly
> so I'll ignore that. If have quite some tests that load stuff into the
> database as a setup step, then run some tricky query procedure, check the
> results, and then clear the DB again. This last step is again a big
> annoyance and a source of incorrectly failing tests.
>
> I actually never use automated tests myself, but, if you do, they probably
> want to start each test with a predictable, pristine database state, and
> likely very small states suffice, right?  So then why not make your testing
> harness manage all this business outside of Ur/Web?
> _______________________________________________
> 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/4be8ff61/attachment.html>