Opened 5 years ago

Last modified 7 days 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@…, Tom Forbes, Krzysztof Szularz, Olivier Tabone, Kye Russell, Semyon Pupkov, Stefan Foulis, Ryan Hiebert, Safwan Rahman, Sébastien Fievet, Paolo Melchiorre, Cesar Canassa, Duane Hutchins, Hannes Ljungberg, Adam (Chainz) Johnson, George Sakkis Triage Stage: Someday/Maybe
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description (last modified by Paolo Melchiorre)

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.

Change History (35)

comment:1 Changed 5 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 5 years ago by Paul Hallett

Type: UncategorizedNew feature

comment:3 Changed 5 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 5 years ago by Marten Kenbeek

Version: 1.7master

comment:5 Changed 5 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 5 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 5 years ago by Tim Graham

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

comment:8 in reply to:  7 Changed 5 years 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 4 years ago by frewsxcv

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

comment:10 Changed 4 years ago by frewsxcv

Cc: frewsxcv added

comment:11 Changed 4 years 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 4 years ago by André Cruz

Cc: andre@… added

comment:13 Changed 3 years 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 although it seems like it's no longer maintained and lacks support from Django 1.8.

comment:14 Changed 3 years 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 years 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 3 years 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).

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

comment:17 Changed 3 years ago by André Cruz

Component: Database layer (models, ORM)HTTP handling
Triage Stage: Someday/MaybeAccepted

Yes, please!

comment:18 Changed 3 years ago by André Cruz

Component: HTTP handlingDatabase layer (models, ORM)
Triage Stage: AcceptedSomeday/Maybe

comment:19 Changed 2 years ago by Tom Forbes

Cc: Tom Forbes added

comment:20 Changed 2 years ago by Krzysztof Szularz

Cc: Krzysztof Szularz added

comment:21 Changed 2 years ago by Olivier Tabone

Cc: Olivier Tabone added

comment:22 Changed 2 years ago by Kye Russell

Cc: Kye Russell added

comment:23 Changed 2 years ago by Semyon Pupkov

Cc: Semyon Pupkov added

comment:24 Changed 2 years ago by Stefan Foulis

Cc: Stefan Foulis added

comment:25 Changed 22 months ago by Ryan Hiebert

Cc: Ryan Hiebert added

comment:26 Changed 19 months ago by Safwan Rahman

Cc: Safwan Rahman added

comment:27 Changed 18 months ago by Sébastien Fievet

Cc: Sébastien Fievet added

comment:28 Changed 15 months ago by Paolo Melchiorre

Cc: Paolo Melchiorre added
Description: modified (diff)

comment:29 Changed 15 months ago by Cesar Canassa

Cc: Cesar Canassa added

comment:30 Changed 11 months ago by Duane Hutchins

Cc: Duane Hutchins added

comment:31 Changed 10 months ago by Hannes Ljungberg

Cc: Hannes Ljungberg added

comment:32 Changed 4 months ago by Adam (Chainz) Johnson

Cc: Adam (Chainz) Johnson added

comment:33 Changed 4 months ago by Adam (Chainz) Johnson

I have a MariaDB/MySQL stable implementation which I've used many times in production. It can provide a starting point:

comment:34 Changed 8 days ago by 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... 🤔)

comment:35 Changed 7 days ago by George Sakkis

Cc: George Sakkis added
Note: See TracTickets for help on using tickets.
Back to Top