[Zope-dev] Re: SQLAlchemy integration experiment

Martin Aspeli optilude at gmx.net
Tue Jun 17 18:14:53 EDT 2008


Martijn Faassen wrote:
> Martin Aspeli wrote:
>> Brian Sutherland wrote:
> [snip]
>>> For some reason this raises a warning bell in my head. I keep on
>>> thinking: this is zope, the session is a classic case for a utility, we
>>> should be getting it in views by an interface.
>> FWIW, I had the same though.
>>
>> I think there's a trade-off here: we can use patterns that SQLAlchemy 
>> and Pylons and others use directly (use a "global" that isn't actually 
>> global) or we can use patterns that are ubiquitous in Zope (look up 
>> utilities by interface).
>>
>> To my mind, the latter is better because it makes us internally 
>> consistent, and because it promotes one of the formalisms that IMHO 
>> makes Zope 3 easier to work with.
> 
> The former integrates smoothly with SQLAlchemy.

Sure, that's why I said "trade-off". :)

> It also is closer to the 
> SQLAlchemy documentation.

This is a good point. But is it "the same" or "almost the same"? If it's 
the latter, the explicitly different is better than faux identity.

> It's also quite likely that someone writing a 
> larger application that does use the interface lookup pattern will get 
> bored and write something like:
> 
> def Session():
>     return component.getUtility(ISession)

Mmmm, I'm not so sure, but maybe.

> The Zope component architecture is not about seeing explicit calls into 
> it everywhere. That's not the point of it. The point of it is about 
> making applications more flexible by allowing people to plug in 
> components. My approach allows you to do that.

Sure, but I also think that the CA has given us a few very basic, very 
flexible idioms (adapters, utilities, subscribers) that permeate any and 
all zope 3 applications. Internal consistency is a very good thing in a 
framework.

A not-quite-global Session variable is another pattern to achieve what 
we do elsewhere with global unnamed utilities when we use them as 
effective singletons. Having two patterns to do the same thing is not good.

Put the question another way - a new user may ask, "why don't I have a 
global thing with a capital first letter like Session to look up other 
singletons?".

> Anyway, the balance can come out somewhere else. People are free to 
> write their own integration approaches, it's just that mine is actually 
>   about trying to make exactly this pattern work in the first place. 
> Then when I succeed people want it changed. :) Anyway, no surprise: I 
> knew that some want other patterns, and I'll be curious to see the other 
> approaches as well.

I'm not saying it's wrong, and I do think "natural" SQLAlchemy is a 
strong selling point, since I'd wager there are more SQLAlchemy users 
than Zope 3 users out there. I just think we need to be careful about 
what patterns we promote and how it fits with the rest of our "story".

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book



More information about the Zope-Dev mailing list