I’m seeking consensus and guidance on how to proceed with Ticket #10244.
My personal leaning is to agree with the second option that Aymeric Augustin offered: Make FileField behave exactly like CharField with regard to null. This would allow actual null values in the database for FileFields instead of empty strings. Are the implications to backward-compatibility acceptable?
I would like to work on this ticket if a consensus can be reached and the current owner is no longer interested.
Ugh, what a mess! I think we should bite the bullet and make backwards incompatible changes to make this sensible in the long term. If we can do this with deprecations to minimise the impact, so much the better.
If we can do this with deprecations to minimise the impact, so much the better.
I believe that one way to achieve that would be to have None resolve to a deprecation period only NoneFieldFile instance (instead of directly to None) that raises deprecation warnings when accessing .name and .path and has a __bool__ -> False.
While we won’t be able to have deprecation warnings point at using model_instance.field_field is None gates they should be able to use if model_instance.file_field and prepare for the eventuality of it returning None in future versions.
NoneFieldFile could then be turned back into None at persistence time and eventually be removed altogether.
This sounds like a good idea, thanks! I can start prototyping this approach.
Are there any other opinions?
Aligning FileField with CharField for null values sounds logical. The NoneFieldFile idea is a smart way to ensure smooth deprecation. Excited to see this improvement.
Thanks for the feedback! I’ll start prototyping this.