Strange behaviour of enums with integer choices

[MiloLug]

I know drf-spectacular optimizes enums so that among enums with the same choices only one will be left.
But in our project we use IntegerChoices and right now it makes the team to add literally every second enum to ENUM_NAME_OVERRIDES. This is a huge inconvenience in big projects.

Here is some example:

### models.py
from django.db import models
from django.utils.translation import gettext_lazy as _


class Availability(models.Model):
    class ScheduleType(models.IntegerChoices):
        WEEKLY = 0, _("Weekly")
        DAILY = 1, _("Daily")

    class DayTimeRangeType(models.IntegerChoices):
        FULL = 0, _("Full")
        PART = 1, _("Part")

    schedule_type = models.IntegerField(
        choices=ScheduleType.choices, default=ScheduleType.DAILY
    )
    time_range_type = models.IntegerField(
        choices=DayTimeRangeType.choices, default=DayTimeRangeType.PART
    )


### serializers.py
from rest_framework import serializers

from .models import Availability


class AvailabilityModelSerializer(serializers.ModelSerializer):
    class Meta:
        model = Availability
        fields = "__all__"

Maybe you should also check the labels of choices to determine, which choice sets are "similar"? Or at least you could make this the default behaviour when dealing with integer choices/enums, since they generally have similar choices.

[tfranzel]

somewhat related to #790

It is a problem that got elevated to a bug since we were adding labels to the description string. This of course can lead to wrong/confusing components. I'm aware and trying to come up with a fix for it soon.

[gabn88]

@tfranzel Thank you for looking into this. This is still one of the main problems we are facing in an otherwise very helpful and great package!

[tfranzel]

It would be helpful if you guys could try out #1113

It introduces an Id into the schema for keeping track of the enum so the mix-up of similar enums does not happen anymore. Those Ids are then cleared afterwards via hook.

[gabn88]

#1113 Fixes this error for us. Thank you!