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/-/w1P2N5cbeL4J. >> 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. >> <deep_deannotate_and_aliased_tables.py> > > > -- > 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.
