On Jun 27, 2007, at 2:01 AM, Mike Orr wrote:
> > Assignmapper is going to be deprecated so I'd recommend not using it > in new code. There were a couple large threads on the sqlalchemy list > about it right before SAContext was developed. Assignmapper hinders > the growth of new Query methods because each one would theoretically > have to be shadowed in the mapped classes, and the code that grafts > those methods in is an ugly monkeypatch. Plus, every new shadowed > method runs the risk of colliding with one of your data attributes > someday. SQLAlchemy 0.4 adds some Query methods that are not > shadowed; the ones in assignmapper are essentially frozen as they are. > The biggest assymetry was having.select() but not .filter(), although > maybe that one got added at the last moment. Assignmapper's biggest > customer was Exilir but I hear they've since moved away from it. > Michael said assignmapper may eventually disappear or parts of it may > morph into something else. > > In spite of all that, sac._session_context should work fine. If > there's enough demand I can make a .session_context property, although > I can't say it's sufficiently justified at this point. > According to Mike and that rather long sqlalchemy-users thread about assign mapper about a month ago, assign mapper itself won't be deprecated. Mike says instead, all of its query methods (.select/.get/ etc) would be removed for using .query().method. The flush method would also be removed. In that case a sac.session_context property is warranted I had a couple other comments about SAContext: o Could we change the PylonsSAContext config file directive key from the redundant 'dburi' to 'uri'? The SAContext constructor's argument is 'uri' too. I don't feel so bad about changing this since coming from pylons.database we've already had to change 'sqlalchemy.' to the preferable 'sqlalchemy.<dbkey>' o create_session can accept a few arguments, might we want the 'echo_uow' option to be accommodated (or others?) for configuring via SAContext, and via a config file in Pylons? Maybe this is something that can be configured via the logging module, I'm not sure, but then again so is engine's 'echo' option. If we do want to support this, I suggest a session_options dict in the constructor, or via the config file as: sqlalchemy.default.session.echo_uow = true (since everything under sqlalchemy.default is an engine_option) o How are multiple databases handled? It seems like the SAContext (well, both of the strategies) session is bound to only one engine in both ContextualStrategys. Though SAContext holds dicts of multiple engines/metadatas. -- 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 -~----------~----~----~----~------~----~------~--~---
