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 <mike...@zzzcomputing.com>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 <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.
>

-- 
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.

Reply via email to