Opened 3 years ago

Last modified 5 weeks ago

#24342 new New feature

Add EnumField model/form fields

Reported by: Thomas Stephenson Owned by: nobody
Component: Database layer (models, ORM) Version: master
Severity: Normal Keywords:
Cc: frewsxcv, andre@… Triage Stage: Someday/Maybe
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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 (or enum34.Enum in python 2).

Change History (16)

comment:1 Changed 3 years ago by Paul Hallett

Needs documentation: set
Needs tests: set

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?

comment:2 Changed 3 years ago by Paul Hallett

Type: UncategorizedNew feature

comment:3 Changed 3 years ago by 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.

comment:4 Changed 3 years ago by Marten Kenbeek

Version: 1.7master

comment:5 Changed 3 years ago by Tim Graham

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

comment:6 Changed 3 years ago by Tim Graham

Needs documentation: unset
Needs tests: unset
Triage Stage: UnreviewedSomeday/Maybe

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.

comment:7 Changed 3 years ago by Tim Graham

Summary: Add an EnumField as standardAdd EnumField model/form fields

comment:8 in reply to:  7 Changed 22 months ago by mmoreaux

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.

comment:9 Changed 20 months ago by frewsxcv

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

comment:10 Changed 20 months ago by frewsxcv

Cc: frewsxcv added

comment:11 Changed 20 months ago by 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.

comment:12 Changed 10 months ago by André Cruz

Cc: andre@… added

comment:13 Changed 4 months ago by 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.

comment:14 Changed 4 months ago by 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.

comment:15 Changed 3 months ago by 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?

comment:16 Changed 5 weeks ago by 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?

Note: See TracTickets for help on using tickets.
Back to Top