[Zope-dev] Re: SQLAlchemy integration experiment

Martin Aspeli optilude at gmx.net
Tue Jun 17 19:24:39 EDT 2008


Laurence Rowe wrote:
> Martin Aspeli wrote:
>> 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".
> 
> I don't think scoped sessions really map well to a utility:
> 
>     session = getUtility(ISession)()
> 
> is just too ugly. Better to stick with Session() or ISession(context)

Agreed.

Why can't it just be

getUtility(ISession)

?

Note that I'm only playing devil's advocate here; I don't feel very 
strongly about this.

Cheers,
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