>
> the joinpoint between A and B is not impicit, there could be many ways
> to join from A to B. We had this guessing going on in 0.3's
> filter_by() and its been removed.
>
Sure, implicit can only work if there is only one possible join path as
specified in either A or B's mapper. If there's more than one path, then
that w/b an error. But ISTM that the case where is 1AO1 path is the 80-90%
case in most schemas.
>
> > One of the big benefits of Query() + eagerload() and it's friends is
> > the abillity to capture and reuse that relational information. Right
> > now, it seems clumsier than it ought to be to join two mapped
> > instances together.
>
> what, query(A).join('foos') ? if that's "clumsy", thats a different
> issue.
Yeah I misspoke a bit -- it's not the join specification itself, it's the
fetching of the other mapped object, as the remainder of the paragraph
implies when you don't split it up like that.
>
> > There is a raft of duct tape like "add_column()", and "add_entity".
> > The basic functionality is there, but the interface is kind of clunky.
>
> well, values(A.id, B.id, C, D), it can all go in there eventually.
>
Right now, from what I've seen from playing with values(), it only takes
column specifications, and complains about instances. It would be a LOT more
useful with the mix of the two. And from there, it seems only a short step
to putting all the fetch specs into the Query() ctor, instead of this
.values() thing.
--~--~---------~--~----~------------~-------~--~----~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
