On Tue, 2011-11-15 at 02:57 +0100, Vlad K. wrote: > This has turned into a much bigger issue than I originally thought it would. > > As suggested by Chris here and Michael on the SQLAlchemy list where I > asked first about refreshing sessions, this problem is solvable if you > reload any model you need after the rollback. But all this fails if I > deal with lists of model instances. I can't reload the list and go > through it again, over and over if any of the list elements causes a > rollback... > > > > It seems to me this is a major bug wrt the Transaction package, unless > there is a solution which I'm currently oblivious to. So the review what > is going on: > > * A subtransaction (created with transaction.savepoint()) fails, eg. > raises IntegrityError > > - Transaction emits rollback (manually invoking > savepoint.rollback() fails) > - If transaction.abort() is not called, the entire request then > fails with InvalidRequestError: This Session's transaction has been > rolled back due to a previous exception during flush
This is the first issue to investigate, I think. Can you provide some code that does something you want to do that has this/these outcome(s)? I can ship it off to the z.sqla maintainer and see if it's expected behavior or what. > - If transaction.abort() is called, the outer transaction (every > model loaded into session between BEGIN and SAVEPOINT) is invalidated > and requires manual reloading > - manual reloading is impossible if you're in the middle of a loop > through a list of loaded models > > Please let me know if I'm being silly or dumb and not seeing something > too obvious, because I'm still learning both SQLAlchemy and how to > properly use the Transaction package, and dealing with IntegrityErrors > in the middle of a view without invalidating entire transaction is IMHO > not some borderline or arcane usage of transactions. > > > > Currently my only choice is abandoning Transaction and writing my own > tween to properly commit or rollback the transaction in uncaught > exceptions -- basically rewrite pyramid_tm not to use Transaction. If I > can avoid that (and rewriting the app to use session directly instead of > transaction), it would be great! > > > Many thanks! > > .oO V Oo. > > > On 11/14/2011 07:50 PM, Chris McDonough wrote: > > I think the issue here is that (for better or worse), calling > > transaction.commit() causes the session to be closed, which detaches the > > objects obtained from that session. The following iteration on your > > script actually completes (note that I requery for "tm" after "second > > pass").... > -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to pylons-discuss@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
