without the flush method I'm not to sure that assignmapper saves much in the way of code, when adding stuff to a database. I do admit I do like the simplified syntax that assignmapper affords you for doing qurery's, and if we are going to keep it with with a query properties that sounds great to me.
BTW is the save method going to be saved? because that would make things better. Jose Philip Jenvey wrote: > 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 -~----------~----~----~----~------~----~------~--~---
