encode
Support UniqueConstraint
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
@carltongibson @tomchristie can we add this to 3.12 milestone? I'm ready to contribute updates to the patch as requested.
Hi @kalekseev. Yes. Super. It's just waiting for a bit of capacity to review. Thanks 👍
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
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.
![stale[bot] avatar](https://avatars.githubusercontent.com/in/1724?v=4 "Published by a pub.dev verified publisher"){kind=small}
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.
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.
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.
Not stale, I will rebase as soon as someone is ready to review. Probably can be superseded by https://github.com/encode/django-rest-framework/issues/7173#issuecomment-1122490298
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?
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.
Not stale, I will rebase as soon as someone is ready to review. Probably can be superseded by #7173 (comment)
if you re start this, with modified approach, I can commit you thorough review for this
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.
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 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?
@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 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.
@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?
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.