From e68377b95b57893c4e9a8fb1851dcffa0bc95383 Mon Sep 17 00:00:00 2001 From: Mike Bayer Date: Tue, 2 Jul 2013 20:35:01 -0400 Subject: [PATCH] for this test, apparently we don't handle sets as unordered since neither does MySQL. for some reason set ordering was constant when testing mysqldb, but not so with oursql. --- test/dialect/mysql/test_types.py | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/test/dialect/mysql/test_types.py b/test/dialect/mysql/test_types.py index fb1de72df9..b918abe256 100644 --- a/test/dialect/mysql/test_types.py +++ b/test/dialect/mysql/test_types.py @@ -511,9 +511,15 @@ class TypesTest(fixtures.TestBase, AssertsExecutionResults, AssertsCompiledSQL): set_table.insert().execute({'s3': set(['5'])}, {'s3': set(['5', '7'])}, {'s3': set(['5', '7', '9'])}, {'s3': set(['7', '9'])}) - rows = select([set_table.c.s3], set_table.c.s3.in_([set(['5' - ]), set(['5', '7']), set(['7', '5' - ])])).execute().fetchall() + + # NOTE: the string sent to MySQL here is sensitive to ordering. + # for some reason the set ordering is always "5, 7" when we test on + # MySQLdb but in Py3K this is not guaranteed. So basically our + # SET type doesn't do ordering correctly (not sure how it can, + # as we don't know how the SET was configured in the first place.) + rows = select([set_table.c.s3], + set_table.c.s3.in_([set(['5']), ['5', '7']]) + ).execute().fetchall() found = set([frozenset(row[0]) for row in rows]) eq_(found, set([frozenset(['5']), frozenset(['5', '7'])])) -- 2.47.2