#23770 closed Bug (fixed)
float("inf") as an argument to a validator breaks migrations
Reported by: | w0rp | Owned by: | Markus Holtermann |
---|---|---|---|
Component: | Migrations | Version: | dev |
Severity: | Release blocker | Keywords: | |
Cc: | info+coding@… | Triage Stage: | Ready for checkin |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Deconstructing float("inf")
in validator arguments breaks migrations, probably because repr(float("inf")) == "inf"
. A similar issue will exist for float("nan")
.
To reproduce this, you'll need a validator using deconstructible.
from django.utils.deconstruct import deconstructible @deconstructible class DoNothingValidator (object): def __init__(self, foo): self.foo = foo def __call__(self, value): pass def __eq__(self, other): return type(self) == type(other) \ and self.foo == other.foo
Now you'll need to pass the validator with float("inf") to a field.
class SomeModel (Model): some_field = IntegerField( validators= [DoNothingValidator(float("inf"))], )
Now if you run 'makemigrations', you will get output like the following.
... ('some_field', models.IntegerField(validators=[some.path.DoNothingValidator(inf)])), ...
The inf
above will cause a NameError when you attempt to migrate, or when you create further migrations with 'makemigrations' again.
Change History (6)
comment:1 by , 10 years ago
Severity: | Normal → Release blocker |
---|---|
Triage Stage: | Unreviewed → Accepted |
Version: | 1.7 → master |
comment:2 by , 10 years ago
Cc: | added |
---|---|
Owner: | changed from | to
Status: | new → assigned |
comment:3 by , 10 years ago
Has patch: | set |
---|
I added a pull request at https://github.com/django/django/pull/3476
comment:4 by , 10 years ago
Triage Stage: | Accepted → Ready for checkin |
---|
Patch looks good (I just have a minor complaint about the alphabetical ordering of imports but that's just cosmetic).
Let's see what the CI has to say.
Thanks!
comment:5 by , 10 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Hi,
I can indeed reproduce this.
I'm going to bump the severity of the ticket too.
Thanks for the detailed bug report!