[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