[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