From: Mike Bayer <mike_mp@zzzcomputing.com>
Date: Wed, 3 Jul 2013 00:35:01 +0000 (-0400)
Subject: for this test, apparently we don't handle sets as unordered since neither does
X-Git-Tag: rel_0_8_2~4
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=e68377b95b57893c4e9a8fb1851dcffa0bc95383;p=thirdparty%2Fsqlalchemy%2Fsqlalchemy.git

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.
---

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'])]))