[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