Hermann Himmelbauer wrote:
Am Sonntag, 25. Mai 2008 13:32 schrieb Andreas Jung:
--On 24. Mai 2008 15:44:01 +0200 Hermann Himmelbauer <[EMAIL PROTECTED]> wrote:
I currently use
SQLAlchemy, but it seems that transactions are managed on the RDB-level
only, which means that the object state is not in the transaction scope.
Huh? If you use one of the integration framework for sqlalchemy-within-zope
then SQLAlchemy is fully integrated with the Zope transaction system.
In my application, I use zope.sqlalchemy and I load my objects from the
database via SA. These objects have interfaces and are related to SA tables
via mappers. If I now change such an SA object and do a transaction.abort(),
a database rollback is issued, however, SA does not restore the object state.
For common cases, this is no problem, as in my application, a transaction
correlates with a HTTP request/response span, and if objects at the end of
the operation are restored or not is of no interest (as data is stored in the
database and the objects are discarded); what counts is that the database
holds the right data.
Nevertheless I have cases (e.g. in testing scenarios) where it makes sense to
manually issue a transaction.abort(). In this case I have to reload the
objects from the database in order to be consistent with the database.
But maybe there's some magic class from an additional z3c package I can
inherit my classes from, which solves this issue?
SQLAlchemy 0.5 has autoexpire support for this use case. It should mean
that zope.sqlalchemy no longer has to do session.clear() on a savepoint
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -