On Nov 24, 2010, at 10:58 AM, Mike Orr wrote: > There are a few limitations with putting the dbsession and initialize > function in a package: > > 1) The model is no longer autonomous. A Pylons model can be imported > and used on its own, even if the rest of the application or Pylons has > some error that makes it unusable. A db utility can simply create an > engine, pass it to init_model(), and not worry about anything else.
There's no reason you can't call setup_dbsession in a command line script. Note in my last email I changed the mock signature of the function to take the settings dict specifically so you wouldn't need a config object. The setup_dbsession could also take raw keyword arguments to set up the db session. Call that, and you're good to go with the models. > 2) If people have multiple databases, they may want to bind certain > tables to certain databases in the Session. In Pylons they can modify > init_model() to take two engines and configure the session. In Pyramid > they'll have to copy the pyramid_sqla code into their application and > modify it. This is not insurmountable, and anyone who's using multiple > databases should be prepared to do this, I'm just pointing out it's a > limitation. AFAIK, you can't just add binds to a session while leaving > the existing binds in place, you have to pass a dict of all the > bindings. Likewise, we could allow multiple prefixes in > initialize_sql() which could create multiple engines, but then what > would we do with the engines? Yep, we can't do everything for everyone, no point trying. When people need crazy customized stuff, they'll have to make their own stuff. No way around that, but I like optimizing for the most common case, which is generally not tons of databases. I'm sure we can work out something somewhat flexible for changing engine bindings to a session on the fly though, like: from pyramid_sqla import set_session_bind set_session_bind(session='read_only', engine='db2') And it'll switch the engine binding for the session for this request. Or we could just provide an easy command that lets the person get the configured engine/session and switch the binding themself, which would prolly be better as that'd let them stick with more SQLAlchemy knowledge, and pyramid_sqla would only be making it easy to register engines/sessions and get to them from anywhere else. > 3) There are really several ways to structure large apps with multiple > databases, such as multiple session objects as Ben last described. I > don't think we can adequately prepare for all of them, because I for > one can't predict what they all will be. So maybe we should just > handle the simple case, and tell the user to make a Pylons-like > structure if they have a complex case. Indeed, so I think a simple central point where you setup/register engines/db sessions would still be useful. The functions would work from a settings dict (like when used with a pyramid app), or keyword args. > 4) Standalone utilities may want to pass an engine to initialize_sql() > rather than creating a fake settings dict. We can handle this by > checking if the first arg is inherited from sqlalchemy.Connection, > otherwise assume it's a settings dict. An alternative would be to > have multiple initialize functions for different situations, although > I can't think of a good name for init_for_engine(). Yep, taken care of per above. :) Cheers, Ben -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-de...@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
