Yup. We screwed up by using metadata.bind but I think we may be stuck with it. Is it possible to bind a metadata collection within a session? i.e would session.configure(binds={metadata_collection_1 : e1, metadata_collection_2 : e2}) work? We would like to be able to bind groups of tables at the same time rather than doing them individually or having a single common bind for the session ... a lot of our applications access data across multiple data-servers and with multiple-logins
pjjH On Sep 24, 12:12 am, Michael Bayer <mike...@zzzcomputing.com> wrote: > On Sep 23, 2009, at 6:36 PM, phrrn...@googlemail.com wrote: > > > > > > > I have a hidden WriterSession which I am using behind the scenes to > > manage a number of API entries that write data in bulk e.g. upsert > > (MappedClass, iterator_that_returns_dicts). I want the session to only > > look at its own binds and to ignore any that are in place on the > > metadata collection. I wrote my own get_bind that does this > > (horrible!) hack: > > > if self._Session__binds: > > b = self._Session__binds > > if c_mapper: > > if c_mapper.base_mapper in b: > > return b[c_mapper.base_mapper] > > elif c_mapper.mapped_table in b: > > return b[c_mapper.mapped_table] > > > if self.bind: > > return self.bind > > > I don't really understand how the double underscore stuff works in > > Python. Mike, how would you feel about exposing the session bind > > information with an interface that is more amenable to subclassing? > > The binds collection on Session is set via the "binds" argument, or > one at a time using bind_mapper() and bind_table(). get_bind() does > not consult the metadata's "bind" unless none of session.bind or or > "__binds" has been configured. So there shouldn't be any need to > hack get_binds(). > > Also I would strongly advise against using metadata.bind for any > application that uses more than one engine. Here's what the 0.5 > docs > athttp://www.sqlalchemy.org/docs/05/metadata.html#binding-metadata-to-a... > have to say: > > Note that the feature of binding engines is completely optional. All > of the operations which take advantage of “bound” MetaData also can be > given an Engine or Connection explicitly with which to perform the > operation. > > Here's what 0.6 has to say > athttp://www.sqlalchemy.org/docs/06/metadata.html#binding-metadata-to-a... > : > > Binding the MetaData to the Engine is a completely optional feature. > The above operations can be achieved without the persistent bind using > parameters: (examples) > > Should you use bind ? It’s probably best to start without it. If you > find yourself constantly needing to specify the same Engine object > throughout the entire application, consider binding as a convenience > feature which is applicable to applications that don’t have multiple > engines in use and don’t have the need to reference connections > explicitly. It should also be noted that an application which is > focused on using the SQLAlchemy ORM will not be dealing explicitly > with Engine or Connection objects very much in any case, so it’s > probably less confusing and more “future proof” to not use the bind > attribute. --~--~---------~--~----~------------~-------~--~----~ 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 sqlalchemy+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---