Fix unique together validator doesn't respect condition's fields

[kalekseev]

fixes #9358

[tomchristie]

@kalekseev - Could you talk me through this?

My understanding is that it's resolving an issue in #7438, is that correct?

[kalekseev]

@kalekseev - Could you talk me through this?

My understanding is that it's resolving an issue in #7438, is that correct?

UPDATE: Yes, this pr is supposed to fix the initial implementation of UniqueConstraint support but at the moment it doesn't work. The problem is that DRF doesn't check if fields in data match the unique constraint condition or not, so for example constraint is:

            models.UniqueConstraint(
                name="unique_constraint_model_together_uniq2",
                fields=('race_name', 'position'),
                condition=models.Q(fancy_conditions__gte=10),
            )

we have record in db that should be unique

        UniqueConstraintModel.objects.create(
            race_name='condition',
            position=1,
            global_id=10,
            fancy_conditions=10
        )

The data below should be valid because it has fancy_conditions=9 that doesn't match constraint condition models.Q(fancy_conditions__gte=10):

       serializer = UniqueConstraintSerializer(data={
            'race_name': 'condition',
            'position': 1,
            'global_id': 11,
            'fancy_conditions': 9,
        })

but this should fail

      serializer = UniqueConstraintSerializer(data={
            'race_name': 'condition',
            'position': 1,
            'global_id': 11,
            'fancy_conditions': 11,
        })

[kalekseev]

@kalekseev - Could you talk me through this?

My understanding is that it's resolving an issue in #7438, is that correct?

@tomchristie I think this PR is ready for review, I described issue in previous comment, the fix is here

https://github.com/encode/django-rest-framework/pull/9360/files#diff-9240f7dfb9eb2cace23eef00e4c922d6e2b6e85dc58b3c9d804e78c6c6227614R27-R34 the rest is just support code to perform that check (make sure that conditional fields values are present in serializer to perform check against condition).

The condition check is actually copy of code from https://github.com/django/django/blob/7ba2a0db20c37a5b1500434ca4ed48022311c171/django/db/models/constraints.py#L672

[auvipy]

we have this separate PR which seems to fix a regression, can you guys please check? #9482

[MaxNstk]

I do not know how the situation is right now but I noticed that when upgrading from the 3.14.0 version to 3.15.2 my condition started to broke. Here is the model:

`
class DailyDataRecord(SynchronizationRecord):

date = models.DateField(verbose_name='Data')
is_active = models.BooleanField(default=False,verbose_name='Ativo')

class Meta:
    ordering= ['-date']
    verbose_name='Registro diário'
    verbose_name_plural='Registros diários'
    abstract=True
    constraints = [
        models.UniqueConstraint(
            fields=['date'],
            condition=models.Q(is_active=True),
            name='%(app_label)s_%(class)s_unique_active_dailyrecord_for_date'
        )
    ]

`

In the current state it stops to check the condition is_active=True and raises and exception if I try to create a new record with is_active=False for the same date.
Ps. The serializer is just a normal ModelSerializer with any model that extends of this class

[SorianoMarmol]

Is a new version expected with this fix and others related like #9531? The support for UniqueConstraint is not complete and may cause issues…

[auvipy]

can you please re base again? we got a separate PR merged

[pauloxnet]

This PR looks ready to be merged (after the rebase), but I've added a few code suggestions.

None of the suggestions are blocking (except maybe removing print in the tests) but in general they all serve the purpose of improving the code itself, or the Git history.

[auvipy]

we need to fix the following failing test as well

FAILED tests/test_validators.py::TestUniqueConstraintValidation::test_unique_together_condition_fields_required
=========== 1 failed, 1542 passed, 13 skipped, 5 warnings in 18.20s ============
py38-django42:

[kalekseev]

@auvipy rebased

[auvipy]

what do you think about this change?

[tomchristie]

@auvipy No. I'm not comfortable with the way this has been merged, completely unclear behavior.

[auvipy]

ops! Ok sorry! I thought comments were addressed! Going to revert this ASAP

[tomchristie]

Please do. We're really clear on https://github.com/encode/django-rest-framework/discussions/9130

This project should be neatly parked.

[kalekseev]

@tomchristie @auvipy I believe I addressed all comments as good as I can. If you have direct question I'm ready to answer them while I'm on that.

[auvipy]

Please do. We're really clear on https://github.com/encode/django-rest-framework/discussions/9130

This project should be neatly parked.

It was a django orm compatibility PR. But doing anyway

[tomchristie]

We're really clear on https://github.com/encode/django-rest-framework/discussions/9130

This project should be neatly parked.

[browniebroke]

I thought that this PR fitted in the first category "Tracking any changes required by updates in Django versions" as Django replaces unique_together with the most powerful constraints API.