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. For example, you statement: > > Lazy loading requires a query for each attribute accessed, just as in > web2py. Is plain false. 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. In SQLA, using a LazyLoading configuration on an attribute, would mean that on the first time (within a transaction) that your code accesses this attribute, it would issue a query to the database. The "Lazyness" here is defined in terms of "when you FIRST access the attribute, and NOT BEFORE" - but as to what happens AFTER that, THEN the caching-mechanism kicks in - if the attribute has not been invalidated within the same transaction, then the LazyLoading is NOT EVEN ACTIVATED (!) You get the value IMMEDIATELY from the attribute-cache. EagerLoading is therefore a way to configure the attribute to be queried from the database EXPLICITLY, but even in THAT case, that would only apply ONCE within a transaction. Every subsequent accesses to that attribute would use the cached-value just as well. > >> As for recursive-queries, it does not occur in eager-loading in SQLA. When >> you eager load in SQLA, it doesn't know ahead of time what attributes you >> will access, so it fetches everything (though in just one, or possibly two >> queries, depending on the eager method used). >> > You are right about that - my mistake - I meant LazyLoading there. But if I understood correctly, than since the Lazynes vs. Eagerness can be configured on a per-attribute basis, you don't necessarily have to load the whole table - you could configure just the fields you want. If you need a complex query for eager-loading, you can simply execute it at the beginning of your transaction - explicitly. You don't even have to store the results anywhere yourself - they are automatically filled-in within their respective attribute-caches across the object-graph. Every access to those attributes thereafter, within the same transaction, would just use those values - regardless of the Lazyness/Eagerness configurations. -- --- 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.
