> In web2py, we have lazy loading for individual references and referencing >> sets, and when that is inefficient, we would just do an explicit join. I >> think an eager loading option on the individual references would be a cool >> addition, though that wouldn't require an ORM layer. >> > > We've been though this already, Anthony, Laziness in web2py has a > different meaning - it uses the same word, but it means something > completely different. >
I'm not going to repeat what I already said -- please go back and read it earlier in this thread. In my statement above, the term "lazy" means* exactly* the same thing as it does in SQLA and that you mean when you say it -- the *database query* is deferred until you access the attribute. > >> Lazy loading requires a query for each attribute accessed, just as in >> web2py. > > > Is plain false. > Or, it's plain true. In SQLA, if you specify lazy loading of relationships (which is the default), the query is deferred until the first time you access the attribute, and there is therefore a query for each attribute accessed. This is in contrast to eager loading, which does a single query to populate all attributes (whether or not they are ever accessed). > There is another mechanism that exists in SQLA that you are not accounting > for, and it is statefullness - a caching-mechanism, using the 'Unit of > Work' pattern. I don't know how many times and in how many forms I need to > say this. > No more times and in no more forms, because nothing I have said has contradicted this. Anthony -- --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
