On Mon, Jan 18, 2010 at 07:24:45PM -0500, Michael Bayer wrote:
> The argument against the tables being broken out in get_bind() is
> partially one of implementation performance and partially one of
> ambiguity, i.e. join of a to b, which table wins ?  Neither argument
> is completely compelling, though a decision on changing this
> behavior is not likely to happen hastily.  Also, we don't support
> persisting one half of the object in one database and the other half
> in another.   Which again is something that is certainly possible
> architecturally, just would require a lot of thought such that it
> doesn't get in the way performancewise of the vast majority of cases
> that don't want to do that.

Wow, sounds like I stumbled on a bit of a deep question here.  Sounds
like a kinda cool idea, pushing parts of objects across databases.
Fortunately, I have no need for that functionality.

> On Jan 18, 2010, at 6:27 PM, Ross Vandegrift wrote:
> > engine = create_engine('sqlite:///:memory:', echo=True)
> > metadata.create_all(engine)
> > binds = { device_table : engine,
> >          switch_table : engine }
> > 
> 
> 
> Currently its looking at the mapped table of each object's class,
> which in this case is a join object, not either of the Table objects
> by themselves.  That might not be ideal, but in any case its better
> if you bind classes and not tables to each engine.  i.e.:
> 
> binds = {
>     DeviceBase:engine,
>     Switch:engine
> }

Wow, talk about a simple fix!  Works perfectly when I concoct things
like that.  Michael, as usual, you are amazing.

Ross

-- 
Ross Vandegrift
r...@kallisti.us

"If the fight gets hot, the songs get hotter.  If the going gets tough,
the songs get tougher."
        --Woody Guthrie

Attachment: signature.asc
Description: Digital signature

Reply via email to