heh well thats the TG thing. I've never used it before or studied it, but I the impression I usually get when others talk about it is that their model of "autocommit" is a bit off.
On May 27, 2010, at 6:50 PM, Kent Bower wrote: > Thank you, as always. > > I failed to recognize I'm using the TurboGears foundation, which uses zope & > transaction: > > Is there a way to still accomplish this? > > >>> DBSession.begin_nested() > <sqlalchemy.orm.session.SessionTransaction object at 0xe9d5150> > >>> > >>> DBSession.commit() > Traceback (most recent call last): > File "<console>", line 1, in <module> > File > "/home/rarch/tg2env/lib/python2.6/site-packages/SQLAlchemy-0.6.0.2-py2.6-linux-x86_64.egg/sqlalchemy/orm/scoping.py", > line 129, in do > return getattr(self.registry(), name)(*args, **kwargs) > File > "/home/rarch/tg2env/lib/python2.6/site-packages/SQLAlchemy-0.6.0.2-py2.6-linux-x86_64.egg/sqlalchemy/orm/session.py", > line 655, in commit > self.transaction.commit() > File > "/home/rarch/tg2env/lib/python2.6/site-packages/SQLAlchemy-0.6.0.2-py2.6-linux-x86_64.egg/sqlalchemy/orm/session.py", > line 368, in commit > self._prepare_impl() > File > "/home/rarch/tg2env/lib/python2.6/site-packages/SQLAlchemy-0.6.0.2-py2.6-linux-x86_64.egg/sqlalchemy/orm/session.py", > line 344, in _prepare_impl > ext.before_commit(self.session) > File > "/home/rarch/tg2env/lib/python2.6/site-packages/zope.sqlalchemy-0.4-py2.6.egg/zope/sqlalchemy/datamanager.py", > line 201, in before_commit > assert zope_transaction.get().status == 'Committing', "Transaction must be > committed using the transaction manager" > AssertionError: Transaction must be committed using the transaction manager > >>> > > > On 5/27/2010 6:39 PM, Michael Bayer wrote: >> On May 27, 2010, at 5:12 PM, Kent wrote: >> >> >>> The docs state "For each begin_nested() call, a corresponding >>> rollback() or commit() must be issued." >>> >>> In PostgreSql, according to my understanding, if there is ever a >>> database exception, a rollback must be issued. >>> This means a main reason to issue a SAVEPOINT is as a hedge against an >>> error. >>> >>> As database transactions go, I want this entire thing to be a single >>> transaction, so now I don't know how to continue... >>> >>> For example, >>> >>> DBSession.begin_nested() #savepoint >>> DBSession.add(obj) >>> try: >>> DBSession.flush() >>> except IntegrityError: >>> DBSession.rollback() >>> else: >>> # now what? I do not want to commit, i have much >>> # more work to do than this which should be part of >>> # this transaction, but if I don't commit now, >>> # i need to issue 2 commits later()?? >>> >>> Is releasing the savepoint a choice instead of rolling() or commit()? >>> >> commit() releases the savepoint, if thats whats going on contextually. It >> doesnt actually commit the outer transaction if you've last called >> begin_nested(). >> >> your block should be like: >> >> session.begin_nested() >> try: >> ... >> session.flush() >> session.commit() >> except: >> session.rollback() >> >> >> > > -- > You received this message because you are subscribed to the Google Groups > "sqlalchemy" group. > To post to this group, send email to sqlalch...@googlegroups.com. > To unsubscribe from this group, send email to > sqlalchemy+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/sqlalchemy?hl=en. > -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
