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 rollback.


Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Reply via email to