Opened 9 years ago

Last modified 2 months ago

#24342 new New feature

Add EnumField model/form fields

Reported by: Thomas Stephenson Owned by: nobody
Component: Database layer (models, ORM) Version: dev
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 Johnson, George Sakkis, kimsia, Olivier Dalang, Ülgen Sarıkavak 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 (38)

comment:1 by Paul Hallett, 9 years ago

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 by Paul Hallett, 9 years ago

Type: UncategorizedNew feature

comment:3 by Thomas Stephenson, 9 years ago

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 by Marten Kenbeek, 9 years ago

Version: 1.7master

comment:5 by Tim Graham, 9 years ago

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

comment:6 by Tim Graham, 9 years ago

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 by Tim Graham, 9 years ago

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

in reply to:  7 comment:8 by Marcel Moreaux, 8 years ago

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 by frewsxcv, 8 years ago

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

comment:10 by frewsxcv, 8 years ago

Cc: frewsxcv added

comment:11 by Tim Graham, 8 years ago

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 by André Cruz, 7 years ago

Cc: andre@… added

comment:13 by Anton Agestam, 7 years ago

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 by Tim Graham, 7 years ago

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 by Mahmoud Hossam, 7 years ago

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 by Ashley Waite, 7 years ago

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 by André Cruz, 6 years ago

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

Yes, please!

comment:18 by André Cruz, 6 years ago

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

comment:19 by Tom Forbes, 6 years ago

Cc: Tom Forbes added

comment:20 by Krzysztof Szularz, 6 years ago

Cc: Krzysztof Szularz added

comment:21 by Olivier Tabone, 6 years ago

Cc: Olivier Tabone added

comment:22 by Kye Russell, 6 years ago

Cc: Kye Russell added

comment:23 by Semyon Pupkov, 6 years ago

Cc: Semyon Pupkov added

comment:24 by Stefan Foulis, 6 years ago

Cc: Stefan Foulis added

comment:25 by Ryan Hiebert, 6 years ago

Cc: Ryan Hiebert added

comment:26 by Safwan Rahman, 5 years ago

Cc: Safwan Rahman added

comment:27 by Sébastien Fievet, 5 years ago

Cc: Sébastien Fievet added

comment:28 by Paolo Melchiorre, 5 years ago

Cc: Paolo Melchiorre added
Description: modified (diff)

comment:29 by Cesar Canassa, 5 years ago

Cc: Cesar Canassa added

comment:30 by Duane Hutchins, 5 years ago

Cc: Duane Hutchins added

comment:31 by Hannes Ljungberg, 5 years ago

Cc: Hannes Ljungberg added

comment:32 by Adam Johnson, 4 years ago

Cc: Adam Johnson added

comment:33 by Adam Johnson, 4 years ago

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

comment:34 by Carlton Gibson, 4 years ago

#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 by George Sakkis, 4 years ago

Cc: George Sakkis added

comment:36 by kimsia, 4 years ago

Cc: kimsia added

comment:37 by Olivier Dalang, 11 months ago

Cc: Olivier Dalang added

comment:38 by Ülgen Sarıkavak, 2 months ago

Cc: Ülgen Sarıkavak added
Note: See TracTickets for help on using tickets.
Back to Top