Primary Support of UniqueConstraint

[kalekseev]

A starting point for discussion, that pr supports both cases when UniqueConstraint consist of one field -> UniqueValidator, and several fields -> UniqueTogetherValidator. The implementation of single field unique validator is quite naive where we loop over all constraints searching for single field constraints and we do it for each field, would be good to cache that somehow.

refs #7173

[kalekseev]

@carltongibson @tomchristie can we add this to 3.12 milestone? I'm ready to contribute updates to the patch as requested.

[carltongibson]

Hi @kalekseev. Yes. Super. It's just waiting for a bit of capacity to review. Thanks 👍

[NyanKiyoshi]

I believe a test case for the serializer error message would be good to have to ensure the message is as expected. Currently it seems like any message is "good enough" which might cause unwanted/unexpected effects

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[kalekseev]

It's not stale, still waiting review from maintainers.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[JorgenPhi]

Bump

[carltongibson]

Just to comment to re-flag this as a change worth having. ORM Constraints are getting increasingly rounded out, and as such are the expected API going forward.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[kalekseev]

Not stale, I will rebase as soon as someone is ready to review. Probably can be superseded by #7173 (comment)

[auvipy]

Not stale, I will rebase as soon as someone is ready to review. Probably can be superseded by #7173 (comment)

so drf level validation might not needed?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[auvipy]

as we still support django 3.0, so we might still follow the approach in this PR. considering the fact that django orm level validation is available in 4.1 mostly.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[auvipy]

if you can fix the merge conflicts it would be really great

[kalekseev]

@auvipy rebased

[auvipy]

I will review it timorrow

[auvipy]

@auvipy rebased

can we check https://docs.djangoproject.com/en/4.0/ref/models/constraints/ and see if we could cover more test cases/edge cases here?

[kalekseev]

@auvipy rebased

can we check https://docs.djangoproject.com/en/4.0/ref/models/constraints/ and see if we could cover more test cases/edge cases here?

The pr lack of support for *expressions that were added recently, I will look into it when I have time.

[auvipy]

@auvipy rebased

can we check https://docs.djangoproject.com/en/4.0/ref/models/constraints/ and see if we could cover more test cases/edge cases here?

The pr lack of support for *expressions that were added recently, I will look into it when I have time.

If you can handle the new API's in this PR it would be really great.

[kalekseev]

@auvipy this is in my backlog, unfortunately I'm crushed with work right now, not sure when I'll be able to review it

as we still support django 3.0, so we might still follow the approach in this PR. considering the fact that django orm level validation is available in 4.1 mostly.

Is there a work done to introduce support for new django validation into DRF?

[auvipy]

not really. in that case we can move forward with the current implementation of this patch for now and implement the new API's in another take.