On Sep 11, 2007, at 11:50 AM, Jean-Philippe Dutreve wrote:
> > Ive uploaded the script eagerload_all.py that reproduce the issue. > Hope it helps you. its actually not eager loading the second list of "accounts" in any case. the reason the first grab doesnt issue a query is because account #1 is already in the session and the many-to-one just does a local get() for it. you can see this if you set echo="debug". also the usage of join_depth is fine, but thats something totally untested, i.e. join_depth on a mapper thats not self-referential, im surprised thats actually doing something. basically the way youre trying to get it to eager load *just* the accounts on the entries on the transaction, and *not* on the entries off the account itself, is entirely something that has never been attempted before. So while I will add a trac ticket for this (#777), more expedient for now would be to construct the exact query you want and apply it using from_statement() in conjunction with the contains_eager() option to indicate the eagerly loaded relations. > > On 11 sep, 16:43, Michael Bayer <[EMAIL PROTECTED]> wrote: >> On Sep 11, 2007, at 10:28 AM, Jean-Philippe Dutreve wrote: >> >> >> >>> The name is on account, not on entry. >>> Transactions and all must be loaded in one shot starting from a >>> single >>> account: >> >>> account (e.g. id=7) >>> ==> all its entries >>> ===> one Transaction for each entry ==> all entries of each >>> transaction (some are different than first ones) ==> the account of >>> each entry >> >>> I need all of this data retrieved in a single SQL SELECT, to be sent >>> in a web page for listing the content of an account. >>> If possible, i don't want to execute a separate select ACCOUNT. >> >> so....account->entries->transaction->entries->account >> >> and youre saying, that the account at the very end is eager loading >> onto "entries" again ? 0.3 definitely should not do that, in 0.4 i >> dont think it should either but thats newer code so i can see how >> that *might* be the case (but im skeptical, because it really would >> just go into an endless loop when it sets up the query if it didnt >> know to stop). >> >> it would be helpful if you could package your tables and mappers >> below into a small test script that runs against SQLite. if the bug >> is there then your script gets adapted into a new unit test. > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
