You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Enums are supported by postgres, mysql, mariadb and oracle. The only Django supported RDBMS that does not support them as native types is SQLite.
They do not offer much advantage over django-enum's implementation using check constraints but one solid reason to support them is to support inspectdb.
MYSQL, Mariadb and Oracle all support enum creation inline with table creation. Postgres requires the Enum type to be created before the table, i.e. CREATE TYPE mood AS ENUM ('sad', 'ok', 'happy');. Its unclear to me how you might generate migrations that do this without monkey patching Django internals.
I would like to support native enum types in the future. Kicking this can down the road to after the 2.0 release.
My current thinking is to add a native toggle as a kwarg to EnumField:
enum_field = EnumField(EnumClass, native=True)
This would resolve to a NativeEnumField type that works on connections other than sqlite and uses the names of the EnumClass as the internal database Enum types. Supporting this on mariadb, mysqldb and oracle seems trivial - postgres is more complicated.
TBD, is there a way to create a 'CREATE TYPE' migration sql statement on postgres without monkey-patching Django internals? Similarly is there a way to support inspect db without monkey patching Django internals? If monkeypatching is required, what is the least brittle, and least invasive way to do it?
Upstream: https://code.djangoproject.com/ticket/24342
Are there any advantages to doing this?
The text was updated successfully, but these errors were encountered: