[Zope-dev] Re: created z3c.saconfig

[Hermann Himmelbauer]

Am Freitag, 20. Juni 2008 13:59 schrieb Martijn Faassen:
> Hey,
>
> Hermann Himmelbauer wrote:
> [snip]
>
> > 1) Why do you need to specify what interface the factory provides, such
> > as here:
> >
> > component.provideUtility(engine_factory, provides=IEngineFactory)
> > component.provideUtility(utility, provides=IScopedSession)
> >
> > Why can't the utilities provide the interface out of the box?
>
> They do, but then registration will only do the right thing if your
> utility only implements a single interface. I also think this makes the
> examples slightly easier to read. Anyway, it's not so important as
> normally registrations would take place from ZCML or using Grok.

Ah, ok, I see.

> > Perhaps it would be best to sketch the most simple case, with the bind
> > parameter first, then explain what the shortcomings of this case are, and
> > then introduce the engine utility.
>
> Yes, perhaps. I'm not sure whether that's a good idea in a tutorial; one
> that shows examples we don't want to encourage first, or the right
> example right away.
>
> Perhaps this could be done in an extra .txt file where we go into more
> detail about various options.

+1

> > 5) For the siteScopeFunc part, it would be best if there would already be
> > a generic one in the SiteScopedSession class, although I don't know if
> > this would be possible. However, this would make things simpler for
> > beginners. Later on I suggest to explain that it's possible to overwrite
> > this method and what it's for.
>
> I haven't found it easy for z3c.saconfig, as I tried to avoid
> dependencies on things like zope.traversing (which again pull in the
> world), or the ZODB. My intent is for z3c.saconfig to be foundational,
> but that other frameworks will need to fill in some more of the holes.
> My aim is to use this with megrok.rdb, and this will certainly offer a
> Grok-specific way to distinguish between applications.

Ah, yes, dependency. Ok, then it should not be included out of the box.

> > The missing bits in this module seem to be:
> >
> > 1) Some way to update database parameters, e.g. change your engine: In
> > many web applications, database setup is done by the user during
> > installation (e.g. PHProjekt and many others). The user has some install
> > wizard and inputs the database parameters here, moreover he can change
> > them later on via a web frontend. I think there should be some
> > solution/guideline that aids the programmer in this part.
>
> I agree that this is still a feature that's missing and should be
> carefully tested.
>
> I'd like to avoid putting knowledge about user interfaces or the exact
> specification of SQLAlchemy parameters in z3c.saconfig though. I'd like
> to offer an infrastructure to reconfigure the engine and then make sure
> the reconfigured engine gets used, but only the minimal one. Again it's
> the task of applications or frameworks that build on top of this to use
> this infrastructure.
>
> > What I can think of is:
> >
> > - Provide some "updateEngine" helper function, that queries a site/global
> > registry for an IEngineUtility and alters the database parameters there
> > - Somthing like I suggested in my code, where there are specific
> > configuration properties in the utility, that, if changed, recreate the
> > engine.
>
> Yes, I saw the property approach. I didn't want to go for the property
> approach, as I thought if you set 3 properties at once, the engine is
> disposed 3 times.

Yes, true, that's not that pretty. However, this has no real bad consequences, 
I think. A simple "updateEngineParameters" function would also be an option, 
btw.

> What I want to offer is an API on IScopedSession and IEngineFactory that
> allows you to replace the engine parameters. This should dispose the
> engine, and then allow for a new engine to be created. I already have a
> sketch of the code on IEngineFactory, taken from your code. That isn't
> enough though, as the scoped session machinery will cache sessions and
> engines indefinitely. We also need an API on IScopedSession therefore
> that can trigger a particular engine (or set of engines) to be throw out
> from the scoped session.

Yes, that looks nice.

> > However, it has to be take special care that when changing the engine,
> > open sessions are not somehow corrupted.
>
> Hm, do you have any details of how this can happen and can be avoided?

I'm not sure about that. I just thought: What happens if someone actually uses 
a session and the engine is concurrently deleted/recreated from the 
EngineUtility?

> > 2) Basically, I can think of 4 main scenarious for a Zope3 + SA
> > integration:
> >
> > a) 1 database per Zope3 instance
> > b) 1 database per Site
> > c) n databases per Zope3 instance
> > d) n databases per Zope3 Site
> >
> > I suggest to outline that in the beginning of the README.txt along with
> > some introductory words and explain that the setup for these cases
> > differ.
>
> I've added some text to the introduction and adjusted the headings for
> case a) and b).

Perfect, right.

> > (a) and (b) seem to be most common and are covered in z3c.saconfig, but
> > (c) and (d) seem to be missing.
>
> c) isn't missing, as b) allows a form of c), right? The idea is that if
> you want multiple databases in an instance, you'd set up multiple sites.

Hmmm, yes, somehow. 

> d) is indeed not covered. I think it's hard to cover in the current
> design. Laurence Rowe is interested in this use case I believe, and
> perhaps we can find ways to make it possible, but I suspect it might
> have to look quite different and use adapters instead of the Session
> class to get sessions. This because to know which database applies to
> which object you need to know more than just what site you are in, but
> also what object you're dealing with.

Well, I basically thought about registering engines as named utilities. So, 
someone would fetch a session explicitly referring to this named utility, 
e.g.:

session = Session('MyDatabase1')

And this named utility could also be global or local. So, this is what I 
thought about (c) and (d).

> We could eventually consider expanding z3c.saconfig with a an
> adapter-driven approach as well to cover this use case.

It seems you think about the idea to bind classes to specific databases. While 
this is an interesting approach, I'm unsure if this will be practically 
useful. The point is, that it may happen, that one class may perfectly match 
to two databases, e.g. when two databases have a table with the same table 
definitions. So, if someone want's to e.g. migrate data, things could become 
complicated for the adapter-driven approach.

Maybe it's best to wait and see if there is demand in these approaches in this 
issue.

Best Regards,
Hermann

-- 
hermann at qwer.tk
GPG key ID: 299893C7 (on keyservers)
FP: 0124 2584 8809 EF2A DBF9  4902 64B4 D16B 2998 93C7