On Tuesday 15 January 2008 17:19:49 Michael Bayer wrote: > On Jan 15, 2008, at 4:33 AM, svilen wrote: > > also, i dont see a reason for it not to work if the (A jon B join > > C) is a polymunion - all the same, all columns will be present > > there, having None where missing. > > > > 0.4.3? > > unlikely, I dont see how it could work from a generic standpoint. > the query generates SQL based on the attributes attached to A. if > it had to also loop through all the attributes of B, C, D, E, F, > etc. and attempt to have all of those add their clauses to the SQL, > theyd all have to assume that the selectable for "A" even supports > receiving their joins, etc.
hmmm, specify explicitly? e.g. query(A).eagerload( B.address) joined-inh via left-outer-join is enough, no need for polymunion. IMO this will be big plus for the ORM - eagerloading polymorphical child attributes - moving further away from SQL-like-looking stuff. i dont know how the current machinery for eagerload works, but imo knowing your level of lookahead-design, it should not be hard to apply that machinery over a polymorphic mapper/query? ciao svilen --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
