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. 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? 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. 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(). -- Mike Orr <sluggos...@gmail.com> -- 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.
