[Grok-dev] Re: Developer scenario
optilude at gmx.net
Wed May 16 18:18:17 EDT 2007
Martijn Faassen wrote:
> For now, I'd suggest looking into z3c.sqlalchemy:
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
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:
and the design patterns here:
More information about the Grok-dev