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

[Laurence Rowe]

Martin Aspeli wrote:
> 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.

Note that sqlite does not support nested transactions or savepoints.


> It's never particularly pleasant.
> 
> Martin
> 

Laurence