feat: enforce Decimal type in min_value and max_value arguments of DecimalField by IsmaelJS · Pull Request #8972 · encode/django-rest-framework (original) (raw)

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 andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Conversation9 Commits2 Checks0 Files changed

Conversation

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters

[ Show hidden characters]({{ revealButtonHref }})

Description

Fixes issue #8963

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am wondering if this enforcement create some noise or might break existing codes which were not using float and decimal in right separation? in that case should we also improve the docs if / where necessary

I am wondering if this enforcement create some noise or might break existing codes which were not using float and decimal in right separation? in that case should we also improve the docs if / where necessary

I think the change may "break" the code but actually is fixing bugs on projects in which those input arguments are not decimal types.
Another approach is to warn a message instead of raising a ValueError, but this doesn't fix/prevent the error.
I agree to document the input type required for these arguments in DecimalField field.

My preference would be to trigger a warning for now and put this through the deprecation cycle. We previously allowed floats, ints, and Decimals and now we are only allowing Decimal. I definitely agree with the goal, but breaking it immediately is probably not the right move.

My preference would be to trigger a warning for now and put this through the deprecation cycle. We previously allowed floats, ints, and Decimals and now we are only allowing Decimal. I definitely agree with the goal, but breaking it immediately is probably not the right move.

I think we should keep supporting Int, float & decimal all. and we should mostly align with django first

My preference would be to trigger a warning for now and put this through the deprecation cycle. We previously allowed floats, ints, and Decimals and now we are only allowing Decimal. I definitely agree with the goal, but breaking it immediately is probably not the right move.

I agree with that a first step should be warn the situation instead of break. The point of @auvipy about aligning with Django is also interesting, because actually a [Min|Max]ValueValidator with any number type can be added to a models.DecimalField. Thus, do you agree guys to only leave a warning message in this PR?

oh I see I miss read it. decimalField should support decimals only. but as it might break existing codes, we should only start with the warning for now :)

we should move towards the path of django but also provide the users a graceful way to fix their code

oh I see I miss read it. decimalField should support decimals only. but as it might break existing codes, we should only start with the warning for now :)

@auvipy done! I also included a test.

It looks like this finally got released, so sorry for the delay, but this really should have used warnings instead of logging a warning. We run our tests flagging warnings as errors, but I just happened to see this in the logs and it was less obvious than it could have been to track down where this was coming from.

I assume this is really only a problem when using float for a min/max value, and we're using an int where this warning could have been ignored.