On 6/20/07, Ben Bangert <[EMAIL PROTECTED]> wrote: > Fixed in latest Pylons trunk with new pylons.config object (there > when the app is initialized and not running, AND there when the app > is running).
"Now you see it, now you do." > > > 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. > > Done in the latest Pylons trunk. Definitely a nice change as well. > > > - 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'll be implementing this as Phil suggested, such that adding another > name with a dot in the config will add more engine's available under > that config key. Ie: > > sqlalchemy.ro_only.dburi = ..... > etc. > > > - 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. > > This will be part of the above implementation for the additional > engine config with a key for usage. Michael and I are still planning on a SAContext object which will make the model metadata-centric rather than sessioncontext-centric, while still dispensing sessions as needed. I guess this can go on top of your multi-engine config-parsing code. It will probably obviate the need to store engines under 'g' at all: engines will be in a SAContext object in the model. It's pretty straightforward, maybe I can get it done this week. Is it OK to go to sqlalchemy.default.dburi for the main engine and sqlalchemy.other_db.dburi for additional engines? That would cut out a bunch of complexity parsing options both with and without a middle part. -- Mike Orr <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
