Awesome! Thank you very much. :) Am Freitag, 30. März 2012 15:47:44 UTC+2 schrieb Michael Bayer: > > really great news, without even any coffee I came up with a patch for this > one in less than 30 minutes. I need to create some tests, maybe try to > figure out why this hasn't been seen more frequently and something should > be committed today. It's on the ticket here: > http://www.sqlalchemy.org/trac/ticket/2453#comment:1 > > On Mar 30, 2012, at 9:35 AM, Michael Bayer wrote: > > well the good news is that these cloning bugs, which have the property > that each time I spend four hours fixing one I'm absolutely convinced it's > the last (a process which began at least four years ago), are my highest > priority since there are usually zero workarounds and also indicate there's > many other places that they can be occurring. > > The call to s._from_obj.union(s._froms) regards keeping a set around of > all the copies of from objects. At the end of the day a particular FROM > can be in these sets any number of times as various clones of itself and is > normal - the actual list of FROMs to be rendered always has a unique list. > > > The issue here centers around Select._froms at line 4769. What happens > here is a SELECT that contains a selectable Q, and a JOIN of Q to R, should > be "hiding" the instance of Q by itself. But the "hiding" logic in this > case isn't matching up the cloned join of Q to R to the Q by itself, so you > get "Q, Q JOIN R" in the FROM clause. The point 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 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 append my testcase. I traced it down > to Select._copy_internals(), line 4907 in sqlalchemy.sql.expression, where > the call to s._from_obj.union(s._froms) will happily add an the initial > table _a second time_ to the FROM clause, (it is already part of the join > object) resulting in an error from the database because the alias is > duplicated in the generated SQL. > > Taking any hints on how to fix this. :) > > Reproduced in 0.7.6 > > thanks, > Christoph > > >
-- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To view this discussion on the web visit https://groups.google.com/d/msg/sqlalchemy/-/jQew87OjnPQJ. 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.
