> On Mar 3, 2017, at 12:52, Mike Orr <[email protected]> wrote: > > On Fri, Mar 3, 2017 at 8:34 AM, Michael Merickel <[email protected] > <mailto:[email protected]>> wrote: >> On Fri, Mar 3, 2017 at 10:10 AM, Mike Orr <[email protected]> wrote: >>> >>> The biggest problem with pyramid_tm I've run into is wanting to >>> rollback or commit the accumulated changes within the view without >>> messing up the global transaction outside the view. Normally when you >>> commit SQLAlchemy starts a new transaction afterward, but with >>> pyramid_tm you have to use 'transaction.commit' and that messes up its >>> transaction for the rest of request processing. >> >> >> Isn't this what savepoints are for? >> >> def view(request): >> sp = request.tm.savepoint() >> try: >> # view things ... >> >> # finally flush to push changes to the db without committing... this >> will >> # raise any IntegrityError, etc >> request.dbsession.flush() >> except Exception: >> # go back to where we were before the view executed >> sp.rollback() > > Ah, I didn't realize you could do that. > >> Obviously a lot of people are confused on this point, and that's an issue. >> The most common cases are usually solved by some combination of savepoints >> and flushing the underlying database session to catch errors earlier. For >> example, SQLAlchemy buffers all of your edits until a flush, and if you >> don't do it manually then it waits until commit. You could catch them >> earlier if you did a request.dbsession.flush() in a try/except (probably >> around a savepoint). > > The issue is that you may set up 'pyramid_tm' because the normal case > applies 99% of the time and seemingly always, and then you already > have an application built and discover that one view needs something > more complex. > > I'll try savepoints and see if that solves it. As for flush, there's a > problem in the opposite direction. If you don't flush then you can > expunge pending adds/deletes from the session and it's like they never > were there. But if you do flush (e.g., to get an autoincrement ID or > fill in server-side defaults), then you can't simply expunge them, you > have to roll back. And if you've written a library function that > flushes, you can't get around the flush without bypassing or rewriting > the function. >
I don’t follow this at all… either way you don’t delete because the transaction is rolled back. > -- > You received this message because you are subscribed to the Google Groups > "pylons-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/pylons-discuss/CAH9f%3DurQY%2BS2Pmccq2uQzT5gED%3D0NARLoQxmTYMpNKVSY5umSA%40mail.gmail.com > > <https://groups.google.com/d/msgid/pylons-discuss/CAH9f%3DurQY%2BS2Pmccq2uQzT5gED%3D0NARLoQxmTYMpNKVSY5umSA%40mail.gmail.com>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/FD6B5A68-E105-446C-AF77-AF9ACF347BED%400x58.com. For more options, visit https://groups.google.com/d/optout.
