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, Hermann -- [EMAIL PROTECTED] GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
