Hello Michael, hello List,
thanks for your previous patch. Most queries of that type do work now.
I am sorry but I have to inform you that I stumbled upon another query
which used these selects in a nested fashion, that triggered the bug. :-}
cheers,
Christoph
--
You received this message
Hello List,
I want to add that for this there exists a workaround for this bug, namely
factoring out the select() and directly putting it into the other
column_properties. This works.
Christoph
Am Dienstag, 3. April 2012 08:59:01 UTC+2 schrieb Christoph Rauch:
Hello Michael, hello List
Hello Michael,
2012/4/3 Michael Bayer mike...@zzzcomputing.com
anyway, this is fixed again by applying my original patch that I thought I
wasn't going to need, so thanks for the very nice testing !
Ah, nice! I'll apply that one then. Thank *you* for all the awesome work! :)
--
Christoph
Hello Michael,
2012/4/3 Michael Bayer mike...@zzzcomputing.com
OK so from the ORM perspective, you're building column_property objects
composed from others right ?
Correct. If I think about it, its totally awesome that this works at all. :)
--
Christoph
--
You received this message
Hello List,
the problem I am facing is that _deep_deannotate, which is used in
ColumnProperty.__init__, breaks the FROM clause of my select() object if
this select() has a JOIN (either left or right, doesn't matter) as from_obj
in it, _where the initial table is aliased_.
To illustrate I'll
of _from_cloned is to
keep track of all the copies of Q.
anyway its ticket http://www.sqlalchemy.org/trac/ticket/2453, I'd like to
get this out today but hopefully it won't be too hard.
On Mar 30, 2012, at 6:50 AM, Christoph Rauch wrote:
Hello List,
the problem I am facing
