There is a maybe/someday ticket for this here: https://code.djangoproject. com/ticket/24342
If your interested you could work on adding this into Django through that ticket, it seems like an interesting idea. When removing an enum value, how do you handle existing records? Are all supported databases consistent in throwing errors if existing rows are still present with a removed enumeration value? On Fri, Oct 20, 2017 at 12:55 PM, Ashley Waite <ashley.c.wa...@gmail.com> wrote: > I've been working a bit on an EnumField implementation because it'll save > me a lot of future time in a project, and existing implementations seem to > be fragile, non-reversible, or one-database-only. Wondering why there isn't > a PEP435 based EnumField in Django itself, I didn't find many answers with > a search on the mailing list. > > Is this a feature that would be considered, and if so, what would the > expectations on it be? > > I was a bit reluctant on all the implementations I could find because they > seem to reduce to these issues: > * Using an int/char instead of database enum > * Being database vendor specific > * Requiring a non-standard enum or sub-class of it > * Not allowing enum reuse > * Not migrating changes statefully (ie, injecting type declaration on > connection in postgres) > * Not allowing enum changes (add/remove/rename) > * Not parametising enum values (mysql) > * Not handling data consistency on enum changes > > And realised, maybe that's why it's not a standard field. > > I've done a POC implementation that works for mysql and postgres, and > should be able to easily generalise to work on any database via two flags > (has_enum, and requires_enum_declaration) that determine how to deal with > changes to it. > > It addresses all of these issues, migrates, and with a little more work > can handle data effects as well. > > So where should I go with this from here? > https://github.com/ashleywaite/django-more/tree/master/django_enum > > - Ashley > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at https://groups.google.com/group/django-developers. > To view this discussion on the web visit https://groups.google.com/d/ms > gid/django-developers/317b5aea-b68f-467b-886d-68a49c7194c7% > 40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/317b5aea-b68f-467b-886d-68a49c7194c7%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFNZOJOqGuKL_eP0TxbL2TaH__j%2BYLKaOJAMQPhFdFWXya7zOg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
