> > Eager-vsLazy loading is configurable - both are supported, and you can use > each in you core, depending on circumstances.
As I said in the previouse message (I updated it since you posted this > one). it depends - the trande-offs are circumstancial - that's why you need > both approaches, and the ability to concigure each object to use one or the > other in different circumstances - and that's what SQLA provides. > 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. > As for recursive-queries, it does not occur in eager-loading in SQLA. > SQLA features what it called a "cascade", which means it "traverses" > through the attribute-accesses, and only fetches what you actually asked > for (well, it's not really "traversing", there are events that are > triggered on each object's attribute-access...) this is for both lazy and > eager loading configurations. The cascade makes sure that you only get what > you explicitly asked for, no more, no less. > 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). Lazy loading requires a query for each attribute accessed, just as in web2py. 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.
