I will continue to poke at it time permitting, and let you know if I figure anything out, and/or if it goes away under 0.8.
thanks again. On Fri, Jan 11, 2013 at 11:30 AM, Michael Bayer <[email protected]>wrote: > if echo=True is affecting it that usually refers to an issue that is > triggered by hash ordering, which is non-deterministic. I've observed that > printing to standard out often has some correlation with hash ordering > going in one direction or the other. > > Seems like you've definitely hit some kind of bug, though. > > > > > On Jan 11, 2013, at 2:00 PM, Bill Curtis wrote: > > I created a runnable .py while that mimicked the tables and models as > closely as possible using a SQLite in-memory engine, but aggravatingly, I > can't reproduce the problem with it. > > I discovered that the problem goes away when you set echo=True > in engine_from_config, the problem goes away, so my guess is that something > on that code path must set use_labels=True on the subload query...? > > I have a "solution" for now, which relies on the fact that we are using > our own Query subclass: I have the subclass always set self._with_labels = > True, before it calls super().__init__(). > > > > > On Thu, Jan 10, 2013 at 12:22 PM, Bill Curtis <[email protected]> wrote: > >> Okay, cool. I'll put together a runnable .py file. >> >> >> >> On Thu, Jan 10, 2013 at 12:19 PM, Michael Bayer <[email protected] >> > wrote: >> >>> I need to run it, so can you express all four tables "profiles", >>> "comments", "articles", "users" with enough columns as are referenced here, >>> and some plain placeholder classes User, Article, Comment, Profile? I >>> don't see the usual things that produce that warning so you might be >>> hitting some subqueryload() issue. In particular, the separate >>> subqueryload() vs. the single subqueryload_all() both indicate the exact >>> same thing, so there should be no difference in behavior. Seeing if you >>> have the same issue on 0.8 would also be helpful but I can test that if you >>> can give me enough code to actually run. >>> >>> >>> On Jan 10, 2013, at 3:02 PM, Bill Curtis wrote: >>> >>> >>> Hi Michael, >>> >>> If you have time to take a look, I put up a short gist with some >>> additional detail: >>> >>> https://gist.github.com/4505226 >>> >>> We are doing this: >>> >>> # 'self' is an Article model, which is 1-to-many with Comments, >>> which are 1-to-1 with Users, which is 1-to-1 with Profile. >>> # All four tables/models have a PK called 'id', which I think is the >>> root cause of the problem. >>> >>> self.comments.options( >>> >>> >>> >>> subqueryload('user')).options( >>> subqueryload('user.profile')).all() >>> >>> which I believe would be better expressed like this: >>> >>> self.comments.options( >>> >>> >>> >>> subqueryload_all('user.profile')).all() >>> >>> When you print the text of the query, the first version is not using >>> AS's in the select, the second version is. >>> >>> BUT, both versions still cause the use_labels warning, so I think the >>> issue is not with the top-level query, but the query/queries being >>> generated to load User and Profile. >>> >>> >>> thanks again, >>> --Bill >>> >>> >>> >>> >>> On Thu, Jan 10, 2013 at 9:24 AM, Michael Bayer <[email protected] >>> > wrote: >>> >>>> >>>> On Jan 10, 2013, at 11:48 AM, Bill Curtis wrote: >>>> >>>> > Hi... >>>> > >>>> > We are seeing many queries generated via relationship() issue this a >>>> warning with this advice: >>>> > >>>> > "Consider use_labels for select() statements." >>>> > >>>> > I'm trying to figure out how to set use_labels, or apply_labels on >>>> the generated query, but I'm completely stumped. >>>> > >>>> > Is it possible to do this, or should I be trying to solve this >>>> problem in a different way? We are using 0.7.9. >>>> >>>> this often has to do with mappings that are to select() constructs >>>> containing multiple tables. It's an advanced situation and I'd need to >>>> see how your mappings look. >>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "sqlalchemy" group. >>>> To post to this group, send email to [email protected]. >>>> To unsubscribe from this group, send email to >>>> [email protected]. >>>> For more options, visit this group at >>>> http://groups.google.com/group/sqlalchemy?hl=en. >>>> >>>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "sqlalchemy" group. >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> For more options, visit this group at >>> http://groups.google.com/group/sqlalchemy?hl=en. >>> >>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "sqlalchemy" group. >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> For more options, visit this group at >>> http://groups.google.com/group/sqlalchemy?hl=en. >>> >> >> > > -- > You received this message because you are subscribed to the Google Groups > "sqlalchemy" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/sqlalchemy?hl=en. > > > -- > You received this message because you are subscribed to the Google Groups > "sqlalchemy" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/sqlalchemy?hl=en. > -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
