[Ur] Explicitly asking for a sql rollback

[Adam Chlipala]

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?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.impredicative.com/pipermail/ur/attachments/20190203/4eb6c49e/attachment.html>