[Grok-dev] Re: Developer scenario

[Martin Aspeli]

Martijn Faassen wrote:

> For now, I'd suggest looking into z3c.sqlalchemy:
> 
> http://svn.zope.org/z3c.sqlalchemy/trunk/

I don't mean to sound negative, since I believe this is a good product, 
but I did use it for a bit and found that it diverged from my needs and 
use cases enough to abandon it.

One showstopper was that it's designed to be somewhat all-or-nothing in 
terms of ORM: you can't mix ORM and lower level queries (well you can, 
but they don't share a connection, so they don't work properly in 
sequence unless you prematurely commit transactions).

It also seemed to assume that a connection string would be known at 
start-up. In my use case, I couldn't know that until run-time (it's 
stored in the ZODB), which required some slightly awkward workarounds 
(basically, late utility registration, and 
un-registration/re-registration when the DSN changed).

I also wasn't too fond of the way it added abstractions on top of 
SQLAlchemy's mappers. By the time I'd translated what I wanted from the 
SA docs into its method of constructing relationships and properties, I 
ended up not saving any time and having to do a few workarounds. That 
part of the story may have improved, of course. Plus, it has 
Postgres-specific features and features designed to support the addition 
of a Zope 2 DA based on SQLAlchemy which I simply didn't need.

I wrote collective.lead instead, which is much simpler. This is back to 
my earlier point that the low-level transaction integration/setup stuff 
should be one package, and higher level abstractions for building data 
models (which z3c.sqlalchemy has) and forms (which it doesn't) should be 
separate and optional.

I'm pretty confident that the transaction integration and setup hooks in 
collective.lead are "right", after discussing the pattern at length with 
various people from SQLAlchemy and people who know the Zope transaction 
machinery.

I'm not 100% sure z3c.sqlalchemy is targetting Zope 3. At least as far 
as I know, Andreas has developed it primarily against Zope 2. I have a 
feeling that if it does work unaltered with Zope 3, then collective.lead 
would too - it's just components.

I blogged about some of this here:

http://optilude.wordpress.com/2007/05/02/im-sorry-i-may-have-nih/

and the design patterns here:

http://optilude.wordpress.com/2007/05/04/component-architecture-design-lessons/

Martin