Combining multiple from_selfs and unmapped ColumnEntity doesn't work

[Former user]

If you build a query, from_self() it, add a ColumnEntity like sql.func.count(), and then from_self() again, the second from_self() will fail to find the corresponding column for the ColumnEntity, resulting in the attached traceback. A test case is also attached as a patch against test_query.py. This kind of query construct is useful for constructing many-to-many histograms without having to use sql expression language, such as building a tag cloud from a set of arbitrary search results.

This behavior begins in r6402 (prior to that the test case passes). I'm not sure if it is intentional or not, however, since the query works without the first from_self(), I am guessing it's a bug.

I found a fix that essentially isolates the broken behavior and reverts to the pre-r6402 behavior for only that case. The better long-term patch would probably be to fix the FromClause.corresponding_column method so that it returns the right column for the aliased ColumnEntity, but I haven't been able to figure out the fix there.

Thanks, Scott Torborg

[Mike Bayer]

wow these are amazing patches you've been sending, will have a look.

[Former user]

Thanks, I guess my code is good at exposing sqlalchemy edge cases... maybe not such a good thing. Please don't hesitate to post if there's anything else I can do to help land stuff like this (more tests, different patch style, etc).

[Former user]

Ok, my teammate Mike managed to find a better fix here, that properly patches FromClause.corresponding_column() to do the right thing in the multiple-aliases case. The test case I posted earlier is wrong, included is a fixed test.

Also, can you add [e-mail] to the cc?

Thanks, Scott

[Mike Bayer]

the fix applies to 0.5 as well but doesn't affect the ORM there, which doesn't handle the kind of from_self() query you're doing in any case - the other fix is that of #1568 and I chose not to merge that into trunk. d24133e5c574676bbc0f30c2186d8da25f550ecb e38962d1e97c08356320e26cc619d460fff607fb

[Mike Bayer]

err sorry I meant chose not to merge #1568 into the 0.5 branch.

[Mike Bayer]

Removing milestone: 0.5.8 (automated comment)