Thanks for your help, Mike! Douglas
On Thu, 11 Aug 2016 at 17:14 Mike Bayer <mike...@zzzcomputing.com> wrote: > > > On 08/11/2016 03:35 PM, Douglas Russell wrote: > > Of course! That makes sense. > > > > Does SQLAlchemy just discard the subqueryload chain parts that are on > > the wrong type? It didn't seem to generate any SQL for those when they > > were wrong. > > it validates the path as far as classes / attributes, but I think when > subclassing and aliasing is used it might be considering just the types, > e.g. a B2 and a with_polymorphic(B, [B2]) are of compatible types. > There's a lot of ways these paths get built up (like with string names > and such), as well as all kinds of "it's worked this way for years" > kinds of things that may not always be present in testing, so more error > checking in there would have to be added carefully. > > > > > > > > An example of this in the docs would be a great idea I think as I think > > it's pretty tough to explain this in the abstract as you say! > > > > Thanks again, > > > > Douglas > > > > On Thursday, 11 August 2016 11:51:39 UTC-4, Mike Bayer wrote: > > > > > > > > On 08/11/2016 09:53 AM, Douglas Russell wrote: > > > of_type was what I was searching for. Thanks. > > > > > > Unfortunately, it did not yield the desired results when I > > extended the > > > hierarchy to 3 levels (C->C2 with a relation between B and C). > > > > > > I've updated the Gist. > > > > > > B+B2 is successfully queried, but C+C2 is not. This will then > > result in > > > lazily generated queries when accessing C2. > > > > > > In fact, it's actually a little more confusing even than that. > > With that > > > query, it does (in the original query) > > > Query for all A+A2 > > > Query for all B+B2 (from the subqueryload) > > > > > > Then once I start to print the hierarchy out, lazy queries: > > > Query for all C > > > Query for each C2 > > > > > > I'm not sure how to document this (I guess just add another example) > > but > > once you've done of_type(), that's now the type you're on and if you > > chain from there, it has to be in terms of that new type. The > > with_polymorphic() object you've made is that type (note the subclass > > namespace that's on the object): > > > > b_b2 = with_polymorphic(B, [B2], flat=True) > > > > r = session.query(A2).options( > > > subqueryload(A2.bs.of_type(b_b2)).subqueryload(b_b2.B2.cs.of_type( > > with_polymorphic(C, [C2], flat=True)) > > ) > > ).all() > > > > > > > > > > > > > > Cheers, > > > > > > Douglas > > > > > > On Wednesday, 10 August 2016 18:18:27 UTC-4, Douglas Russell wrote: > > > > > > Hi, > > > > > > I have two (well, more than two with more than two levels > > each, but > > > this is the simplest recreation of the problem) parallel > > > joined-table inheritance hierarchies > > > > > > A -> A2 > > > B -> B2 > > > > > > B.a is a relationship to A, backref in A.bs. > > > > > > The problem arises when I want to query this whole structure > back > > > with subqueries. The desired number of queries in this case > > would be > > > twoish, depending on how the polymorphic queries are done. At > any > > > rate, the desire is to remove any lazy loading at all. > > > > > > The problem lies in formulating a subqueryload which will do > > this. > > > My first thought was: > > > > > > | > > > session.query(A2).options(subqueryload(A2.bs)).all() > > > | > > > > > > The problem with this is that what I wanted was all the A2s > > and all > > > the B2s, but what I get is all the A2s, and all the Bs. When I > > > access a property of B2, it lazy loads that single record. > > > > > > I think the best solution is something along the lines of > using a > > > combination of subqueryload and joinedload (or maybe > > > with_polymorphic?) to say: Give me all the A2s with a subquery > > for > > > all the B2s linked to it. I can't figure out how to do this as > > the > > > arguments to subqueryload and joinedload are relationships > > which I > > > don't currently have. > > > > > > Minimal Test > > > Case: > > https://gist.github.com/dpwrussell/508e8b33fe92434eafe001ee806f355a > > <https://gist.github.com/dpwrussell/508e8b33fe92434eafe001ee806f355a > > > > > > > <https://gist.github.com/dpwrussell/508e8b33fe92434eafe001ee806f355a > > <https://gist.github.com/dpwrussell/508e8b33fe92434eafe001ee806f355a > >> > > > > > > Is there a clever way to handle this? > > > > > > The only thing I've done which works is to add a relationship > > > between B to B2: > > > > > > | > > > b = relationship('B', backref='b2') > > > | > > > > > > Then I can do: > > > > > > | > > > r = > > > > > session.query(A2).options(subqueryload(A2.bs).joinedload(B.b2)).all() > > > | > > > > > > but it would be better if I didn't have to go and add these > > > relationships to the existing models as there are several > levels, > > > repositories and (most hinderingly) jurisdictions in play in > > my real > > > project. It seems likely that there is a clever way as > SQLAlchemy > > > does such a good job with the polymorphic queries usually. > > > > > > Cheers, > > > > > > Douglas > > > > > > -- > > > 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+...@googlegroups.com <javascript:> > > > <mailto:sqlalchemy+unsubscr...@googlegroups.com <javascript:>>. > > > To post to this group, send email to sqlal...@googlegroups.com > > <javascript:> > > > <mailto:sqlal...@googlegroups.com <javascript:>>. > > > Visit this group at https://groups.google.com/group/sqlalchemy > > <https://groups.google.com/group/sqlalchemy>. > > > For more options, visit https://groups.google.com/d/optout > > <https://groups.google.com/d/optout>. > > > > -- > > 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 > > <mailto:sqlalchemy+unsubscr...@googlegroups.com>. > > To post to this group, send email to sqlalchemy@googlegroups.com > > <mailto:sqlalchemy@googlegroups.com>. > > Visit this group at https://groups.google.com/group/sqlalchemy. > > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to a topic in the > Google Groups "sqlalchemy" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/sqlalchemy/mu56muQI6tM/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > sqlalchemy+unsubscr...@googlegroups.com. > To post to this group, send email to sqlalchemy@googlegroups.com. > Visit this group at https://groups.google.com/group/sqlalchemy. > For more options, visit https://groups.google.com/d/optout. > -- 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 https://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
