this might be a bug introduced in 0.4.6, it would be helpful if you could post a full test case as a trac ticket. Though im not sure how this would have worked in 0.4.5 either since I don't think we have any coverage for this exact scenario and there wasn't any "aliasing" logic removed AFAIK.
On May 21, 2008, at 12:07 PM, Bobby Impollonia wrote: > > Hi. If I have a many-to-many relation between Class1 and Class2, the > following query: > Class1 > .query > .filter > (Class1.class2s.contains(obj1)).filter(Class1.class2s.contains(obj2)) > , where obj1 and obj2 are instances of Class2, generates the following > sql in .4.6: > > SELECT <lots of columns> > FROM class1, secondary > WHERE class1.id = secondary.class1_id AND %s = secondary.class2_id AND > class1.id = secondary.class1_id AND %s = secondary.class2_id > > Note that the secondary table isn't being aliased for each contains(), > so this will never return anything unless obj1==obj2. I think this > used to use separate subqueries (with Exists) for each contains(), so > this query worked before .4.6. (I only have .4.6 installed, so I can't > verify). > > Also, if obj1 and obj2 aren't actually instances of type Class2 but > are instead instances of some other mapped class that don't belong in > this relation, SQLA happily uses them in the above query if they have > a column with the same name as Class2's primary key. I would think > that throwing an exception in that case would be better behavior? > > > --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
