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?

Best Regards,

GPG key ID: 299893C7 (on keyservers)
FP: 0124 2584 8809 EF2A DBF9  4902 64B4 D16B 2998 93C7
Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to