Dear Mike, I've read the doc string in the new sacontext and was just wondering why for add_engine_from_config do you have to explicitly pass None for the default connection? it would make more sense to pass 'default' or better yet nothing all all and assume the default engine. I understand that you are moving away from the the implicit to the explicit which is great, I just thought passing None to mean default is awkward when you could just as easily added None as the default in the method def. (the same could be said about add_engine)
Just my two-cents-worth Jose On 7/10/07, Mike Orr <[EMAIL PROTECTED]> wrote: > > > SAContext is a SQLAlchemy front end that organizes your engines, > metadatas, and sessions into one convenient object, while still > allowing access to the underlying objects for advanced use. > > Version 0.3.0 attempts to handle and document all the use cases that > have been thrown at it: one database, multiple databases permanently > connected to tables, one engine per session, multiple engines per > session. There are several backward-incompatible changes and > undoubtedly some new bugs. Get it now at: > > http://sluggo.scrapping.cc/python/sacontext/ > http://cheeseshop.python.org/pypi/sacontext > > > The biggest change is that .__init__ no longer configures a default > engine, so you'll have to call .add_engine where you previously > didn't. Likewise, PylonsSAContext.add_engine no longer reads the > Pylons config file; you'll have to call the new method > PylonsSAContext.add_engine_from_config for that. Explicit is better > than implicit. The default engine is keyed under None, so adding > engines is: > > sac.add_engine(None, uri="...") > # default engine from explicit args > # The first arg is the engine key: None or a string > sac.add_engine_from_config(None) > # "sqlalchemy.default.uri" -> default engine > # The first arg is the same as above > sac.add_engine_from_config("logs") > # "sqlalchemy.logs.uri" -> "logs" engine > sac.add_engine_from_config("logs", config_key="db2") > # "sqlalchemy.db2.uri" -> "logs" engine > sac.add_engine_from_config(None, "verde") > # "sqlalchemy.verde.uri" -> default engine > > The module docstring is expanded to explain the various use cases. > > SAContext._get_session_scope now returns the thread ident. The > previous implementation was wrong and thread unsafe. > PylonsSAcontext._get_session_scope is unchanged; it uses the same > methodology as pylons.database.app_scope. > > I haven't used Exilir or Tesla so I don't know how compatible > SAContext is with them. A couple people have said they're trying it > but none have given me feedback yet. (Hint) > > SAContext is no longer supported under Pylons 0.9.5. Pylons had some > internal changes I didn't realize, and I think our time would be > better spent preparing for 0.9.6. So use PylonsSAContext with a > recent development version of Pylons. > > SAContext will soon get an update soon for SQLAlchemy 0.4; in > particular the new 'bind' attributes/arguments. I don't know if it > will remain compatible with SQLAlchemy 0.3.x after that. > > We are discussing ways to incorporate SAContext into Pylons, possibly > for 0.9.6, but nothing is finalized yet. It may be under > pylons.database or it may be in a separate distribution. > > -- > Mike Orr <[EMAIL PROTECTED]> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
