#10244: FileFields can't be set to NULL in the db
-------------------------------------+-------------------------------------
Reporter: oyvind | Owner: nobody
Type: Bug | Status: new
Component: Database layer | Version: 1.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: filefield NULL | Triage Stage: Accepted
empty |
Has patch: 1 | Needs documentation: 1
Needs tests: 1 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by dvg):
From ten years ago:
> ... only for people who set null=True on a FileField. The docs
discourage that heavily ...
As far as I can see, there is no mention of `null`, at all, in the
*current* documentation for
[https://docs.djangoproject.com/en/4.0/ref/models/fields/#filefield
FileField].
Yet Django's `FileField` behavior is still plainly inconsistent, compared
to other fields, when it comes to `null=True`.
A short summary:
We can specify `null=True`, and we can assign `None` to the field, but
this is stored as a `FieldFile` with `name=None` on the python side, and
it is stored as an empty string `''` in the database.
Some resulting inconveniences:
- `MyModel.objects.create(my_filefield=None).my_filefield is not None`
- `my_model_instance.my_filefield` is always "truthy", so we need to check
e.g. `my_filefield.name` ([https://stackoverflow.com/q/8850415 example])
- we cannot use the `__isnull` field lookup, but have to check for
equality with the empty string `''` ([https://stackoverflow.com/q/4771464
example])
- `FileField(null=True, unique=True)` is broken, because the database
entry is `''` instead of `null`, so we get a unique-constraint violation
if we try to create another instance with `None`
The latter is basically what is described in the
[https://docs.djangoproject.com/en/4.0/ref/models/fields/#django.db.models.Field.null
model field reference] (my emphasis):
> ... One exception is when a `CharField` has both `unique=True` and
`blank=True` set. In this situation, `null=True` is *required to avoid
unique constraint violations when saving multiple objects with blank
values*.
So, currently, we cannot make a `FileField` unique and optional at the
same time.
Why not just bite the bullet and make a backward incompatible change, for
the sake of consistency?
[1]:
https://docs.djangoproject.com/en/4.0/ref/models/fields/#django.db.models.FileField.storage
[2]: https://docs.djangoproject.com/en/4.0/ref/models/fields/#filefield
[3]: https://stackoverflow.com/q/8850415
[4]:
https://docs.djangoproject.com/en/4.0/ref/models/fields/#django.db.models.Field.null
[5]: https://stackoverflow.com/q/4771464
[7]:
https://docs.djangoproject.com/en/4.0/ref/models/fields/#django.db.models.fields.files.FieldFile
--
Ticket URL: <https://code.djangoproject.com/ticket/10244#comment:19>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/0107018124e515ab-17f7291a-7abb-4798-923d-fe37b46e2ddc-000000%40eu-central-1.amazonses.com.
