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.

1 files changed, 9 insertions, 3 deletions

diff --git a/test/dialect/mysql/test_types.py b/test/dialect/mysql/test_types.py
index fb1de72df..b918abe25 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'])]))