[Zope-dev] straighting out the SQLAlchemy integration mess

[Kapil Thangavelu]

On Tue, Apr 8, 2008 at 5:54 PM, Martijn Faassen <faassen at startifact.com>
wrote:

> Hi there,
>
> [I originally picked this up on a thread on zope3-users, but this deserves
> its own thread here]
>
> There are at least three approaches to SQLAlchemy integration with Zope:
>
> * z3c.zalchemy (Christian Theune)
>
> * z3c.sqlalchemy (Andreas Jung)
>
> * collective.lead (Laurence Rowe)
>
> 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... :)
>
> Then there's also mentions about WSGI-based integration, and I think in
> Plone, Alchemist probably also does its own integration...


ore.alchemist works with sqlalchemy 0.4 series, and i've been doing z3 rdb
only apps with it over the last year.  i'm biased, but i think it has the
easiest api integration of any of the others..

>> from ore.alchemist import Session

thats it.. all you need for transaction integration with sa, no magic
utilities to setup mappers, or tables.

the rest is as documented by sqlalchemy. it goes on to provide additional
zcml syntax for defining connections and binding them to sqlalchemy
metadata, but usage is optional.

as for the wsgi based integration, to get zope3 without the zodb, i use
ore.wsgiapp which just defines a utility which is the traversal root. i'd
like to refactor it to use the new zope.publisher paste support directly, as
it currently it includes a bunch of boiler plate from a generated


> There must be a reason for this proliferation of approaches. What is it?
>  We all get along, don't we? I know that the various packages are taking
> code and approaches from each other too.


we all had different needs, some wanted to play in z2 land where broken egg
requires are the name of the game, some in z3 land... some were just the
first to arrive. i wanted and implemented higher level semantics to generate
interfaces from tables, and vice versa, and automatically generate forms
etc.


>
>
> Can't we work together more and at least come up with *one* package that
> works? Perhaps factor out some low-level commonality than then all share?
> Criticize one of the other packages until you're satisfied, and then retire
> your own package perhaps? I know the various packages add on their own
> approaches to configuration and might offer higher level container
> approaches. Those could be in different packages, sharing a foundation.
>
> In the end, I hope we will end up with just *one* integration layer, that
> is released, that works with Zope 2 and Zope 3 and a recent release of
> SQLAlchemy, that is documented, and that people know about. We can then
> offer packages on top of this that offer extra features.


that sound good, i'd like to see a common base layer, providing transaction
support, simple containers.

cheers,

kapil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.zope.org/pipermail/zope-dev/attachments/20080409/1ddb80d4/attachment.htm