On Apr 9, 2007, at 10:06 PM, Huy Do wrote:
> > Michael Bayer wrote: >> Particularly for your query you are doing an eager load between >> "asset" and "location" yet a lot of your query criterion depends upon >> "location", so in that sense yes you have to use custom SQL, since >> query() will never involve eager loaded joins in the query criterion. > > Hi Michael, > > Everything you say makes perfect sense for 1:N relationships, but > in my > case, and with alot of other cases where I need the order by or the > criteria/filter on the joined table, it's a 1:1. In these cases I'm > not > sure why SA can't generate the same type of SQL statement that I am > above. It would make perfect sense for it to. > > I understand the eagerload problem with a list of child objects but > with > 1:1 relations I think the query interface should be querying in the > same > way that my manual SQL is. sorry, i just dont think that the loader strategy should *ever* have any effect on the primary results...otherwise loader strategies become intertwined with querying, and mappers become brittle since you can no longer change eager/lazy loads without breaking the results of your query. additionally for the eager loaders to guess when they should create non-aliased criterion and when they should create aliased criterion would be magical and complicated, and render improvements to eager loading impossible since people would be structutring their queries off of a now expected behavior which could then never change. it also implies that a lazy-loading mapper setup would break when eager loading is enabled via options, since the eager loader "expects" that its going to be used in query criterion, doesnt apply its aliases, and then changes the results of the query. so it definitely breaks a lot of widely accepted behavior. there are tools to join eager loads with query criterion which are contains_eager() and instances() or explcit select() objects passed to query.select(). id favor adding new mapper options to generate criterion that is simlar to that of the eager loader (such as, using contains_eager() with a Query-compiled query will add the columns in and the join for you) but loader strategies by default will never purposefully inject themselves into application query criterion. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
