[Zope-dev] Re: Zope3 on Google AppEngine

Laurence Rowe l at lrowe.co.uk
Fri May 30 15:19:08 EDT 2008


Hermann Himmelbauer wrote:
> Am Sonntag, 25. Mai 2008 13:32 schrieb Andreas Jung:
>> --On 24. Mai 2008 15:44:01 +0200 Hermann Himmelbauer <dusty at qwer.tk> 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.

Laurence



More information about the Zope-Dev mailing list