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 <[email protected]> wrote:
> On Sep 23, 2009, at 6:36 PM, [email protected] 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 [email protected]
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
-~----------~----~----~----~------~----~------~--~---
