-
-
Notifications
You must be signed in to change notification settings - Fork 7k
Support violation_error_code
and violation_error_message
from UniqueConstraint
in UniqueTogetherValidator
#9766
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support violation_error_code
and violation_error_message
from UniqueConstraint
in UniqueTogetherValidator
#9766
Conversation
What's the use case for that? (Why not use model-level default?) |
…ture Extracted error message logic to a separate method. fix: conditionally include violation_error_code for Django >= 5.0 fix(validators): use custom error message and code from model constraints
24e69af
to
c54c658
Compare
Returning the constraint’s default message would change the output and might break users relying on the validator’s default message—for example, in tests or UI rendering. I consider that the current behaviour should be maintained. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good overall, just minor questions!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm! Let's wait for @browniebroke's comment on the open conversation and then we're done!
Hi @browniebroke! Just a quick ping in case this got lost — would be great to get your review when you have time. |
Thanks for the patience and pinging again, I indeed missed that. Will try to take a look this week |
That looks good to me. Will have to wait a bit for merging at we are working out the next version to release (3.16.2 or 3.17) and when. Thanks for your patience |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR adds support for custom violation error codes and messages from Django model-level UniqueConstraint definitions to be passed through to UniqueTogetherValidator in Django REST Framework serializers.
- Enhanced UniqueTogetherValidator to accept and use custom error codes and messages
- Updated serializer logic to extract custom violation messages and codes from UniqueConstraint objects
- Added comprehensive test coverage for both custom and default error handling scenarios
Reviewed Changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
File | Description |
---|---|
rest_framework/validators.py | Enhanced UniqueTogetherValidator with code parameter support and updated error handling |
rest_framework/serializers.py | Added constraint lookup logic and violation message extraction to pass custom codes/messages to validators |
tests/test_validators.py | Added test model and test cases to verify custom and default error message/code behavior |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
ea44b67
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm!
violation_error_code
and violation_error_message
from UniqueConstraint
in UniqueTogetherValidator
Added support for retrieving custom violation_error_code (for django 5+) and violation_error_message from Django model-level UniqueConstraint definitions and passing them to UniqueTogetherValidator.
refs #9714 and #9352
The update ensures that:
• If violation_error_message or violation_error_code are explicitly defined on the model constraint, they are forwarded to the corresponding validator.
• If the constraint uses the default message/code, they are not passed, allowing the validator to use its own defaults.
Additionally, tests have been added to cover both scenarios:
• When a custom error message/code is used.
• When defaults are applied.
Note: The current structure of
get_unique_together_constraints()
may benefit from refactoring (e.g., returning a named structure for clarity and extensibility). This is outside the scope of this PR, but I may explore it in a future contribution.