revisiting #7726

[Dan Watson]

We were recently bitten by a backwards-incompatible change that seemed to creep in between 1.2.4 and 1.2.5. DecimalFields that define max_digits == decimal_places used to be valid until #7726 [1]. When trying to upgrade to 1.2.5, several models failed validation. Changing them such that max_digits=decimal_places+1 worked around the problem, but means we need to take an extra validation step to ensure the value is < 1. As Karen Tracey mentioned in #7064 [2], numeric(x,x) is perfectly valid at the database level, so it seems strange that Django would not support this. It seems like what may have happened was:

  1. #7064 was opened

  2. #7726 was opened before #7064 was fixed, i.e. you could not successfully save a decimal field at the time, since the normalized representation has a leading 0.

  3. #7064 was fixed (in my opinion, obviating the need for #7726)

  4. #7726 was fixed, essentially overriding #7064

Unless I'm misunderstanding something, I'd propose rolling back #7726, since #7064 made it possible to use (and create) decimal fields with max_digits == decimal_places.

Regards,

Dan

[1] https://code.djangoproject.com/ticket/7726

[2] https://code.djangoproject.com/ticket/7064

[Russell Keith-Magee]

Rolling back #7726 isn't the right fix here, because it catches a
legitimate validation case (decimal places > max_digits). However, the
check is a little overenthusiastic. From a quick inspection, I think
modifying the validation condition on line 77 to be a > rather than >=
should do the trick.

This should be opened as a separate ticket (tracking the "max_digits
== decimal_places is legal, but raises validation error" problem);
given that it's a regression from 1.2.4, it should also be marked as a
release blocker.

Yours,
Russ Magee %-)

[Dan Watson]

Thanks for the feedback, here's the ticket with a patch:

https://code.djangoproject.com/ticket/16570

Dan