On May 25, 2007, at 10:23 AM, Michael Bayer wrote:
>
> Forgive my attention grabbing headline but I think Pylons integration
> with create_engine() needs a serious overhaul, small as it may be.yes
Oh yes. Don't worry, I hate it too
>
> id like to apply the "pool_recycle" argument to create_engine().
> however pylons.database provides no way to propigate arbitrary keys
> from the .ini file to create_engine(); its hardcoded to just "dburi"
> and "echo". Additionally, if I stick a pylons.database.create_engine
> () statement inside of config/environment.py, pylons.database will
> cache that particular engine based on its URI as well as the string
> version of its **kwargs, therefore pylons.database.session_context
> still has no way to get at those options, since it doesnt have those
> **kwargs with which to construct the key. but not only that, its not
> even caching it in the same dictionary that the running application
> will use.
>
> i tried using this code in environment.py:
>
> kwargs = {}
> uri, echo = database.get_engine_conf()
> kwargs['echo'] = echo
> database.get_engines()['%s|%s' % (uri, str(kwargs))] =
> database.create_engine(uri, echo=echo, pool_recycle=7200)
>
> which would at best be a horrible kludge to get this working, as i am
> imitating a private key-making function to make it work. but even
> *that* doesnt work, because get_engines() at that point returns the
> _db_engines dict thats inside of database.py, but when the app
> actually runs, it returns the _db_engines thats on top of "g".
> setting it within lib/app_globals.py doesnt do any better. So I have
> to stick it inside of lib/base.py which is not at all where
> environmental options should be configured.
>
> design changes i would make:
>
> - definite: have just *one* dictionary which stores database engines,
> not two. database._db_engines and g._db_engines, if you even need
> g._db_engines at all (why is it needed in two places?) should be *the
> same dictionary*. having two of the same thing is useless and
> creates ambiguity.
We were storing it under g as g is specific to your application (you
might have more than one Pylons apps deployed in the same process).
The database._db_engines came about because g isn't initialized in
many cases (like websetup.py). I suppose having all engines cached in
the module dict wouldn't hurt -- but we have to keep in mind that
there may be multiple Pylons apps.
We need to make it easier for things like websetup.py to
automatically have access to g, and any StackedObjectProxy that is
around during the request.
> - no reason why not: alter pylons.database.create_engine() to
> provide a "config_key" argument, which specifies exactly what key a
> particular database engine will be stored under. put this key as
> in .ini as well under sqlalchemy.key or similar so it can be affected
> from both places.
I've been meaning to switch to using an identifier. Like,
sqlalchemy.readonly.dburi = 'sqlite://memory'
sqlalchemy.readonly.pool_size = 2
And maybe the default of no identifier would use sqlalchemy.dburi and
the like.
> - nice to have: allow support for *any* keyword under
> sqlalchemy.XXXXX to be propigated from the .ini file to create_engine
> (), not just 'uri' and 'echo'. have awareness of the well known
> kwargs so that types can be changed from strings to ints/booleans as
> needed.
>
How would one easily setup non int/bool/str options to pass to
create_engine? Like import pyodbc; module=pyodbc, or poolclass=Pool
()? If we want to maintain the default
pylons.database.session_context, you need to intercept the keyword
arguments passed along to create_engine with python code. Maybe with
a setuptools entry point?
I've been avoiding any big changes to the SQLAlchemy support stuff
until it's fully sorted out.
--
Philip Jenvey
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---
