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()
> Do the 'pyramid_tm' revisions offer any help with these cases?
>
pyramid_tm's goal is to provide a path for "normal" requests. This means
throughout the request you add data to the transaction created by
pyramid_tm and it will commit it eventually provided no errors occur. You
should try *really really hard* not to commit that transaction on your own
because obviously when you do you're making a lot of assumptions about what
code comes next.
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).
As far as your logging comment, this has always been the case that you may
have things you want to commit to the database outside of the "normal"
request. For example, errors, activity / login times, etc. These don't
belong on pyramid_tm because they aren't contingent on whether the request
succeeds or not. This has been a large driver for why the alchemy scaffold
/ cookiecutter was rewritten to get rid of a global database session. You
can now create as many sessions as you want, and you don't have to hook
them all to pyramid_tm - you can manage them individually in their own
lifecycles.
Hope this helps!
- Michael
--
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/CAKdhhwEX5yqSfKJfMLnWmcKGeRB_v-WVEhsQ6adBbVTmTCz-tg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
