<div dir="auto">About your first comment,<div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">On the second part, </div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">Simon </div></div><br><div class="gmail_quote"><div dir="ltr">On Sun, Feb 3, 2019, 1:29 PM Adam Chlipala <<a href="mailto:adamc@csail.mit.edu">adamc@csail.mit.edu</a> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <div class="m_-7718098031233654965moz-cite-prefix">On 2/3/19 5:24 AM, Simon Van Casteren
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <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">
      <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>
  </div>

_______________________________________________<br>
Ur mailing list<br>
<a href="mailto:Ur@impredicative.com" target="_blank" rel="noreferrer">Ur@impredicative.com</a><br>
<a href="http://www.impredicative.com/cgi-bin/mailman/listinfo/ur" rel="noreferrer noreferrer" target="_blank">http://www.impredicative.com/cgi-bin/mailman/listinfo/ur</a><br>
</blockquote></div>