[Zope-dev] Re: SQLAlchemy integration experiment

[Martijn Faassen]

Martin Aspeli wrote:
> Martijn Faassen wrote:
[snip]
>> 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.

It's not quite the same. While a utility can be scoped per application, 
the Session class also takes care of scoping per thread. I'm not sure 
whether utilities can be convinced to do so (sites are local per thread, 
but utilities?).

SA's ScopedSession also takes care of creating and caching individual 
sessions for each thread (and application), something utilities don't 
really do either. So you'd still have to use ScopedSession and register 
that as a local utility somehow, or do some componentry I can't wrap my 
head around yet. I have a strong suspicion it'll become a lot more 
complicated than my approach (and not more flexible). I'm trying to go 
with the flow for *both* frameworks. The code is pretty simple right 
now, and this is a good sign.

> 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?".

A new user won't ask such a thing, as it looks like he's importing and 
instantiating a class. Classes are singletons, and they're imported. 
I've actually wished for a long time that utility lookups could be made 
to look more like imports. :)

It's a question a very experienced user might ask.

>> 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 want to promote the "import Session and instantiate it" pattern. :)

If people want to override certain behavior of session creation, *then* 
I want to promote the "implement and register a utility that provides 
this interface" pattern. I hope to supply the user with enough 
pre-implemented IDatabase utilities that this is rare, so that they just 
end up registering them. A simple global one, and a local one that 
allows for flexible engine configuration somehow.

What the Zope 3 integration I propose changes is how Session is set up. 
By using utilities we can offer flexibility to set it up globally or 
locally with ZODB-stored configuration. We use SA's mechanism of 
actually creating and managing sessions. I think that's a good division 
of labor: hook into SA with a bit of Zope 3 component architecture for 
configuration and pluggability, and leave the rest to SA.

Regards,

Martijn