Am Sonntag, 25. Mai 2008 13:32 schrieb Andreas Jung:
> --On 24. Mai 2008 15:44:01 +0200 Hermann Himmelbauer <[EMAIL PROTECTED]>
> > 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?
GPG key ID: 299893C7 (on keyservers)
FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -