-
-
Notifications
You must be signed in to change notification settings - Fork 32.7k
Fixed #17854 -- Added database-specific validation for DecimalField max_digits and decimal_places limits. #19654
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
base: main
Are you sure you want to change the base?
Conversation
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.
Hello! Thank you for your contribution 💪
As it's your first contribution be sure to check out the patch review checklist.
If you're fixing a ticket from Trac make sure to set the "Has patch" flag and include a link to this PR in the ticket!
If you have any design or process questions then you can ask in the Django forum.
Welcome aboard ⛵️!
errors.append( | ||
checks.Warning( | ||
"%s does not support DecimalField with max_digits > 38." | ||
% self.connection.display_name, | ||
obj=field, | ||
id="oracle.W001", | ||
) | ||
) | ||
|
||
if field.decimal_places > 127: |
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.
Any reason not to create, per database backend, constants variables at module or class scopes for the values used to verify the max_digits
and decimal_places
, and then reuse them in validation and messages?
Okay, maybe the only benefit of this is the reduction in duplication of hardcoded numbers in the codebase and messages and the reduction in the number of places that need to be changed if a new database version changes it limits.
Another question is whether the constant variables should be in the public API or in the private API of the database backend.
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.
Yup absolutely these magic numbers would need to be removed 👍
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.
I agree, we should set something like max_digits = None
and max_decimal_places = None
to django.db.backends.base.features.BaseDatabaseFeatures
and update these for the specific backends
This also means if the backend changes the limit, we can calculate it based off the database version (as we do with other flags here)
I also think the validation should be within django.db.models.fields.DecimalField._check_decimal_places
and django.db.models.fields.DecimalField._check_max_digits
. You can look at the GeneratedField
checks for inspiration on getting database specific validation
Also think that the error id's should be within fields
and documented once.
Trac ticket number
Ticket-17854
Branch description
Add database-specific DecimalField validation for precision limits
Add warnings when DecimalField max_digits/decimal_places exceed database limits:
Includes tests and documentation updates.
Checklist
main
branch.