IntegerField declared as blank=True,null=True on model, and part of a unique_together, is showing up as required=True in default model serializer

[uraniumanchor]

Fields/Meta are declared thus in my models file (heavily trimmed down for relevancy):

    event = models.ForeignKey('Event', on_delete=models.PROTECT)
    order = models.IntegerField(
        blank=True,
        null=True,
        validators=[positive],
    )

    class Meta:
        unique_together = (('event', 'order'))

But when trying to use a default ModelSerializer to create, if the field is not included in the POST data, it complains that the field is required.

I think I tracked down the issue to these lines in get_uniqueness_extra_kwargs:

                if default is empty:
                    uniqueness_extra_kwargs[unique_constraint_name] = {'required': True}

There are lines in get_field_kwargs in field_mapping.py later on that do the right thing:

    if model_field.has_default() or model_field.blank or model_field.null:
        kwargs['required'] = False

However, in get_fields it combines these (incorrectly?) and the former overrides the latter:

            field_kwargs = self.include_extra_kwargs(
                field_kwargs, extra_field_kwargs
            )

Inspecting the values in the debugger immediately before this block looks like this:

extra_field_kwargs = {'required': True}
field_kwargs = {'allow_null': True, 'max_value': 9223372036854775807, 'min_value': -9223372036854775808, 'required': False, 'validators': [<function positive at 0x1118fc860>]}

Afterwards, required has changed to True.

Additionally, the UniqueTogetherValidator does not seem to take into account the nullability of the field and triggers a validation error.

Setting 'required': False explicitly on the Serializer's Meta.extra_kwargs field fixes the former, but 'default': None is required to fix the latter. Setting 'default': None by itself causes an assertion error than default cannot be provided if required is True.

[browniebroke]

This is some great debugging work! Some of these findings explain the behaviour reported in #9378