<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 2/3/19 5:24 AM, Simon Van Casteren
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAC0+czrokGw0S-nefQxk1cW_id0K8M5YKZmJuXyFLH26Kx+MmA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="auto">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.
<div dir="auto"><br>
</div>
<div dir="auto">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. <br>
</div>
</div>
</blockquote>
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 <i>after</i> all validation,
so that no special code complication is needed.<br>
<blockquote type="cite"
cite="mid:CAC0+czrokGw0S-nefQxk1cW_id0K8M5YKZmJuXyFLH26Kx+MmA@mail.gmail.com">
<div dir="auto">
<div dir="auto">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.</div>
</div>
</blockquote>
<p>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?<br>
</p>
</body>
</html>