I just read Micheaael's note on what is changing in version 0.4. A must read or all of us using sqlalchemy jsoe
Jose Galvez wrote: > 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 -~----------~----~----~----~------~----~------~--~---
