<br><br><div class="gmail_quote">On Tue, Apr 8, 2008 at 5:54 PM, Martijn Faassen <<a href="mailto:faassen@startifact.com">faassen@startifact.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi there,<br>
<br>
[I originally picked this up on a thread on zope3-users, but this deserves its own thread here]<br>
<br>
There are at least three approaches to SQLAlchemy integration with Zope:<br>
<br>
* z3c.zalchemy (Christian Theune)<br>
<br>
* z3c.sqlalchemy (Andreas Jung)<br>
<br>
* collective.lead (Laurence Rowe)<br>
<br>
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... :)<br>
<br>
Then there's also mentions about WSGI-based integration, and I think in Plone, Alchemist probably also does its own integration...</blockquote><div><br></div><div>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..</div>
<div><br></div><div>>> from ore.alchemist import Session</div><div><br></div><div>thats it.. all you need for transaction integration with sa, no magic utilities to setup mappers, or tables.</div><div><br></div><div>
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.</div><div><br></div><div>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</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
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.</blockquote><div><br></div><div>
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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
<br>
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.<br>
<br>
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.</blockquote>
<div><br></div><div>that sound good, i'd like to see a common base layer, providing transaction support, simple containers. </div><div><br></div><div>cheers,</div><div><br></div><div>kapil</div></div>