Michael Bayer wrote: > 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. > I don't think I understand the internals of SA enough to appreciate this response; i.e it went way over my head :-)
I'm going to stick to the select->instances way for all my query ORM needs. I like it. (I guess I was after some DRY with contains_eager() and relation() having to be specified twice). I'll use the mapper/relation for CRUD stuff only. Thanks for your responses Michael, its very much appreciated. It's getting harder to keep up with SA these days. It's moving forward so quickly. Regards, Huy > 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 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 -~----------~----~----~----~------~----~------~--~---
