Add EnumField model/form fields

[Thomas Stephenson]

Add support for an EnumField which is backed by the corresponding enum type if one exists in the database engine (eg. mysql, postgres), with a default implementation of CharField in other database types and mapped to instances of the enum.Enum.

[Paul Hallett]

This sounds like a good idea considering the new enum type in Python 3.4, but the enum34 package would have to be added to Django's requirements to support backwards compatibility for versions < 3.4.

Would this basically replace the need to use choices in CharField?

[Thomas Stephenson]

For us, it has replaced the use of choices everywhere, although we don't use django forms (django only powers our REST API). The enum names are stored in the database column and the implementation is agnostic to the enum values. Our implementation is currently postgres specific, but should be relatively easily to make generic.

But there are (dubious) use cases supported by choices that can't be easily filled by enums (such as defining named groups of values in a <select> form element), so I don't think choices can be deprecated entirely. Perhaps an optional form_groups argument to EnumField would satisfy this use case if a decision to deprecate choices were made in response to this.

[Tim Graham]

Could you please raise the issue on the DevelopersMailingList to see if there is consensus to add this to core?

[Tim Graham]

The ​mailing list thread didn't reveal a strong consensus to add this to core at this time. My sense is that it might be more appealing once the minimum version of Python that Django supports has enums (3.4+).

The mailing list thread also noted ​django-enumfields as an active third-party implementation.

[Marcel Moreaux]

Replying to timgraham:

The mailing list thread also noted ​django-enumfields as an active third-party implementation.

It's worth noting though that django-enumfields is CharField-based and doesn't use the database-specific enum types. So it's not a full replacement for the feature requested here.

[frewsxcv]

If someone (maybe myself?) wrote a PostgreSQL specific EnumField, could it be added to django.contrib.postgres?

[Tim Graham]

The idea of a PostgreSQL-specific field was rejected on the mailing list thread link in comment:6. Quoting Josh Smeaton:

I definitely do not like the idea of building a feature into contrib.postgres that could be built for the rest of the database backends too. It seems like a cop-out for doing less work, and really promotes one built in backend above others. contrib.postgres should be a place for postgres specific features, not for cutting out other backends.

[Anton Agestam]

Now that the next version of Django will drop support for Python versions <3.5, will pull requests for this feature be considered?

Also thought it was worth mentioning ​https://github.com/5monkeys/django-enumfield although it seems like it's no longer maintained and lacks support from Django 1.8.

[Tim Graham]

Yes, a patch would certainly help advance the conversation -- particularly if you can highlight the advantages of this as part of Django rather than as a third-party package.

[Mahmoud Hossam]

I'm interested in implementing this feature, but I have a question regarding backend support.

MySQL and PostgreSQL both have native types to support this feature, but SQLite and Oracle don't.

How should we go about supporting this feature on those two databases?

[Ashley Waite]

I've implemented a POC that uses postgres and mysql enums (and will add a fail to char for others) handling all the migrations cases (changing enum, adding/removing values, etc).
​https://github.com/ashleywaite/django-more/tree/master/django_enum

Is a pull to add these changes something that will be considered?

[André Cruz]

Yes, please!

[Adam Johnson]

I have a MariaDB/MySQL stable implementation which I've used many times in production. It can provide a starting point: ​https://django-mysql.readthedocs.io/en/latest/model_fields/enum_field.html

[Carlton Gibson]

#31861 was a duplicate. Maybe the position is advanced some by the enum choices available since 3.0.

Tim's comment:14 stills seems telling: a 3rd-party package showing what's feasible is the first/next step, then a discussion of whether to bring that into core.
(Wondering if this is wontfix pending such... 🤔)