From c307df6596dab489109cd216665cf30006b70d13 Mon Sep 17 00:00:00 2001 From: Mike Bayer Date: Mon, 15 Oct 2012 17:21:38 -0400 Subject: - [feature] "scalar" selects now have a WHERE method to help with generative building. Also slight adjustment regarding how SS "correlates" columns; the new methodology no longer applies meaning to the underlying Table column being selected. This improves some fairly esoteric situations, and the logic that was there didn't seem to have any purpose. - [feature] Some support for auto-rendering of a relationship join condition based on the mapped attribute, with usage of core SQL constructs. E.g. select([SomeClass]).where(SomeClass.somerelationship) would render SELECT from "someclass" and use the primaryjoin of "somerelationship" as the WHERE clause. This changes the previous meaning of "SomeClass.somerelationship" when used in a core SQL context; previously, it would "resolve" to the parent selectable, which wasn't generally useful. Related to [ticket:2245]. --- test/sql/test_selectable.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'test/sql/test_selectable.py') diff --git a/test/sql/test_selectable.py b/test/sql/test_selectable.py index 374147a1b..bbf7eeab1 100644 --- a/test/sql/test_selectable.py +++ b/test/sql/test_selectable.py @@ -62,11 +62,11 @@ class SelectableTest(fixtures.TestBase, AssertsExecutionResults, AssertsCompiled eq_( s1.c.foo.proxy_set, - set([s1.c.foo, scalar_select, scalar_select.element, table1.c.col1]) + set([s1.c.foo, scalar_select, scalar_select.element]) ) eq_( s2.c.foo.proxy_set, - set([s2.c.foo, scalar_select, scalar_select.element, table1.c.col1]) + set([s2.c.foo, scalar_select, scalar_select.element]) ) assert s1.corresponding_column(scalar_select) is s1.c.foo -- cgit v1.2.1