Changes between Version 5 and Version 6 of Ticket #10244, comment 19
- Timestamp:
- Jun 7, 2022, 7:24:24 AM (2 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #10244, comment 19
v5 v6 9 9 A short summary: 10 10 11 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. 11 We can specify `null=True`, and we can assign `None` to the field, but this is stored as a `FieldFile` with `name=None` (initially) on the python side, and it is stored as an empty string `''` in the database. After e.g. `refresh_from_db`, the `FieldFile.name` will also be an empty string, instead of `None`. 12 13 Basically, this passes: 14 15 {{{ 16 obj = MyModel.objects.create(my_filefield=None) 17 assert not MyModel.objects.filter(my_filefield__isnull=True).exists() 18 assert obj.my_filefield is not None 19 assert isinstance(obj.my_filefield, FieldFile) 20 assert obj.my_filefield.name is None 21 obj.refresh_from_db() 22 assert obj.my_filefield.name is not None 23 assert obj.my_filefield.name == '' 24 }}} 25 12 26 13 27 Some resulting inconveniences: … … 22 36 > ... 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. 23 37 24 So, currently, we cannot make a `FileField` unique and optional at the same time .38 So, currently, we cannot make a `FileField` unique and optional at the same time, in the database. 25 39 26 Why not make a backward incompatible change (for the next major release), for the sake of consistency? 40 This also breaks e.g. `get_or_create` for `FileField`. 27 41 42 Why not make a backward incompatible change for the next major release, for the sake of consistency? 43