[Zope-dev] Re: straighting out the SQLAlchemy integration mess

Martin Aspeli optilude at gmx.net
Wed Apr 9 21:00:16 EDT 2008


Martijn Faassen wrote:
> Martijn Pieters wrote:
>> On Tue, Apr 8, 2008 at 11:54 PM, Martijn Faassen <faassen at startifact.com> wrote:
>>>  All of these are in various states of brokenness. z3c.zalchemy doesn't work
>>> with SQLAlchemy trunk. collective.lead works with it, but only if you check
>>> out a particular branch, and not with sqlite. Quite possibly z3c.sqlalchemy
>>> has a release that actually works. One out of three is not bad... :)
>> We are going into production with collective.lead and are committed to
>> releasing the 1.0 branch as 1.0. sqlite works just great for us, we
>> use it to run unit tests and for developers that just need to adjust
>> the styling and such. The production environment will run against
>> Oracle.
> 
> The elro-tpc branch (which, I was told, is the future) doesn't appear to 
> work with sqlite out of the box.

I think this is a temporary bug, as Laurence pointed out, caused by 
SQLite not supporting two-phase commit. It should be fixed before 
release, by adding a one-phase fallback.

> I'm curious how to do functional tests with collective.lead - I'd like 
> to have some real easy way to get the database set up and tore down down 
> in my tests. Are you doing this?

I'm doing a lot of it in Java. :) The typical pattern is to use a test 
setup that does database clean-down to return it to a steady state. Test 
data is kept in a declarative file (e.g. with an XML syntax that maps to 
DB structure) and used to initialise the database before each run.

Doing nested transactions and rollback would be nicer, but probably 
doesn't work in all cases since app code may well do explicit commits.

It's never particularly pleasant.

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book



More information about the Zope-Dev mailing list