Ok, I think I understand some of the reasoning behind not wanting to implement such a feature. I think this is fine, because I don't need the magic that hibernate provides.
However, I'm still stuck with the current problem of how to do this kind of collection populating with our antique sybase instance. The kind of sub queries needed to do what subqueryload provides, even if I am able to modify the dialect, are probably not possible in our database version. However, I know the lazy loading works for a single entity. Is there anything I could easily modify to have subqueryload (or some extension of it) trigger a second query, instead of wrapping the original search with a left outer join? I imagine if this were implemented behind the scenes as two separate requests, then you wouldn't have the same kind of ambiguous cases you described above. Anyway, I'm not asking that you implement something into SQLAlchemy, more looking for guidance on a way to support this kind of query (possibly via some manual extension of the API). Sure, I could just write a specific query to do this, but I want an approach that utilizes the details of each collection's relationship, since this paradigm will be common in our app. Even if it's a bit ugly to do, I think we'd be fine with it, since we only need to support sybase for another year. Then we can migrate our app to Postgres. On Saturday, November 1, 2014 1:33:26 PM UTC-4, Michael Bayer wrote: > > > > On Nov 1, 2014, at 11:53 AM, Kevin S <kevin...@gmail.com <javascript:>> > 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.
