[Zope-dev] Re: straighting out the SQLAlchemy integration mess

[Martin Aspeli]

Andreas Jung <lists <at> zopyx.com> writes:

> > The way I use collective.lead in my book is to have it look up the
> > database settings in a local utility. That utility is editable via a
> > control panel page in Plone. I suspect that it'd be quite easy to do
> > something similar where the settings were deferred to a global utility
> > configured with ZCML or looked up in a config file of some sort.
> >
> > Once the config is available, it's all about calling getUtility() to get
> > hold of a database connection/session.
> 
> Possibly a sane and clean solution but way of over-designed. I am 
> interested in simple and robust solutions that work and not in a solution 
> that adds more and more unnecessary layers just the sake of having them 

collective.lead doesn't enforce this style at all. If you want TTW configurable
connections, though, it's a good pattern to use.

All collective.lead does is:

 - Set up database connections and engines properly
 - Hook into transaction machinery so you don't need to do your own transaction
management
 - Let you look up a database session/connection as a utility

You need to register that utility, of course. Lead has a base class that means
you just fill in a few template methods (database url, and some callbacks for
configuring tables and orm classes).

If you want some kind of config-file based or ZCML based version, you'd just
construct an appropriate class and register it as a utility on startup. Lead
doesn't want to enforce one particular connection parameter configuration model
or config file format. That should be the job of a higher level package that is
concerned only with getting these parameters, not with the database setup itself.

However, you probably still need some imperative code to set up the tables and
mappers.

Martin