The recipe "Storing/Using Enumerations" does not function in SQLite

[rgg]

The recipe "Storing/Using Enumerations", described in http://techspot.zzzeek.org/2011/01/14/the-enum-recipe/ does not function in SQLite using the latest SQLAlchemy version (from the repository).

It fails when it tries to create the CHECK constraint associated to the Enum field. The constraint receives the values associated to the enum symbols, but requires the symbols, and it fails when trying to get the values of the symbols.

In PostgreSQL (which uses a native ENUM type) the recipe works ok.

I suppose it will fail in all databases which don't have a native Enum type, but I have verified the failure only on SQLite.

Regards,

[Mike Bayer]

this is due to #2838.

removing the naive calling of cached_bind_processor:

diff --git a/lib/sqlalchemy/sql/compiler.py b/lib/sqlalchemy/sql/compiler.py
index 22906af..4c5700f 100644
--- a/lib/sqlalchemy/sql/compiler.py
+++ b/lib/sqlalchemy/sql/compiler.py
@@ -954,9 +954,9 @@ class SQLCompiler(Compiled):

     def render_literal_bindparam(self, bindparam, **kw):
         value = bindparam.value
-        processor = bindparam.type._cached_bind_processor(self.dialect)
-        if processor:
-            value = processor(value)
+        #processor = bindparam.type._cached_bind_processor(self.dialect)
+        #if processor:
+        #    value = processor(value)
         return self.render_literal_value(value, bindparam.type)

     def render_literal_value(self, value, type_):

recipe works again.

the regression in 0.9 is due to the greater usage of render_literal_bindparam() introduced in #2742.

[Mike Bayer]

this is resolved by #2742 but after closer inspection i think there's some type mechanics that should be affected here too, the custom DeclEnum should not be subject to the CHECK constraint that is receiving strings, will coerce that.

[Mike Bayer]

45ad8af3f97f2e6eee21ca3219827e82e3231cdf 0.8

0b0764b62ba87bdec41d0fc86618f3779cb4e3f0 master

even with #2742, if the DeclEnum started implementing the upcoming "process_literal_param()", the same failure would occur.

[Mike Bayer]

Removing milestone: 0.8.xx (automated comment)