> On Nov 1, 2014, at 11:53 AM, Kevin S <kevinrst...@gmail.com> wrote: > > I think I've seen this sort of functionality in Hibernate, where it tries to > optimize if you are going to access some lazy loaded property on a collection > of objects. It can load them in batches, as opposed to one query for every > object.
we offer the “subqueryload” feature. However this load is not “on-demand” when an attribute is accessed, it’s established up front as the total collection of objects are loaded. Hibernate’s feature of doing this on demand is not something I can get my head around, really. It links the loading of a collection to how the object was loaded in the first place, and to the query that loaded it. I can hardly count the number of ambiguous edge cases that come to mind with that. What if query A loads objects X, Y, Z, query B loads objects P, Q, Y, then I access P.collection, does Y.collection get loaded, and if so, what if I had accessed X.collection instead? If we say that query A should stay with object Y, what about the subtle case where Y falls out of scope in the user’s application, then is loaded with query B, now we have Y.collection that may be loaded from A or may be loaded from B based on a subtlety of memory management which will confuse users. It’s not just that a query of X.collection or P.collection can trigger Y.collection - queries A and B might have different options set up which can change how related objects past Y.collection are loaded too. Overall, how do I manage memory, if 1000 objects were loaded with 1000 queries I have to carry around all 1000 query objects with each object? What if the object is serialized? What if the object was expired, does that expire that it’s connection to its original query? I would imagine that in Hibernate’s case, these edge cases just exist in some awkward way and there’s not much way to question it - this was my observation with a lot of Hibernate behaviors :) - everything sort of worked, though once in awhile not, and if you could even find a community where people were describing and questioning the behavior clearly they weren’t really getting any answers. This is a big reason Hibernate, while being brilliant software that I’ve learned much from and used extensively, has still managed to earn kind of a bad reputation regardless. For SQLAlchemy, this feature it seems a little more exotic than what folks need and would come at a significant cost in terms of maintenance, dealing with inconsistencies in edge cases and end-user confusion, which we take very seriously. So anyway yes I’m familiar with this feature and I implemented “subqueryload” as a response to it, e.g. same kind of loading idea but avoids the ambiguity of linking every object to a set of originating queries. this is not to say this feature couldn’t be implemented but it seems like a steep hill to climb. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
