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 <b...@beautylish.com> wrote: > Okay, cool. I'll put together a runnable .py file. > > > > On Thu, Jan 10, 2013 at 12:19 PM, Michael Bayer <mike...@zzzcomputing.com> > 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 <mike...@zzzcomputing.com> >> 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 sqlalchemy@googlegroups.com. >> To unsubscribe from this group, send email to >> sqlalchemy+unsubscr...@googlegroups.com. >> 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 sqlalchemy@googlegroups.com. >> To unsubscribe from this group, send email to >> sqlalchemy+unsubscr...@googlegroups.com. >> 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 sqlalchemy@googlegroups.com. > To unsubscribe from this group, send email to > sqlalchemy+unsubscr...@googlegroups.com. > 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 sqlalchemy@googlegroups.com. > To unsubscribe from this group, send email to > sqlalchemy+unsubscr...@googlegroups.com. > 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 sqlalchemy@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
