On Nov 15, 2011, at 11:39 PM, Michael Bayer wrote: > > On Nov 15, 2011, at 8:54 PM, Alex Grönholm wrote: > >> query = session.query(Z, A.name).outerjoin(Z.b).filter(Z.id == 1) >> print query >> >> # WORKAROUND: >> # query = session.query(Z, A.name).outerjoin(Z.b).filter(Z.id == 1) >> # ^- use the superclass instead > > I'd note that these two queries are written exactly the same, and I'd assume > the first one intends to ask for "B.name". If you're telling the ORM that > you'd like "B" objects, the WHERE criterion is added (which in a significant > plurality of cases is necessary), since it would be invalid to return rows > that are of type A but not of type B, i.e. those where the value of "disc" is > not 'b'. > > In this case, the outerjoin to Z.b also adds this same criteria to the ON > clause, thereby making the WHERE redundant but because its an outer join also > affecting the results, thus escalating it to "erroneous". SQLAlchemy can't > however figure out that the outer join elsewhere in the query is sufficient > in order to apply the necessary limiting of rows. Its a bug (ticket > http://www.sqlalchemy.org/trac/ticket/2328) but unfortunately it's extremely > difficult to track and correlate these two conditions accurately, else it > would already be doing so.
The ticket does have a patch that seems to resolve this but it needs a lot more tests before it can be committed. -- 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.
