#17224: determine and document the use of default option in context of FileField
--------------------------------------+------------------------------------
Reporter: ptone | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: File uploads/storage | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------------+------------------------------------
Comment (by ymph):
Hello,
I am the reporter of the bug #24823.
Just my 2 cents on this problem.
I know that the documentation of FileField is explicit ("A file-upload
field.") but I think that in certain use cases the semantic of this field
has changed to be a field simply referencing a file, whatever its origin.
This is especially true for the ImageField that add some convenient
attributes to manipulate image. This semantic shift is even bigger in
packages that add fields that derive form ImageField or FileField, like
the packages that helps in the manipulation of thumbnails.
In this case the duplication of the file pointed by the value makes not
always a lot of sense. For example, one may need to update the content of
the "default" field for all instances pointing to it. If the file has been
duplicated, this otherwise very simple operation can be now quite
difficult.
For the default value of the FileField, I would recommend to have the same
behavior as the char field (plus the initialization of the `instance.file`
property). This is indeed the current behavior for string default value
and since there is no warning in the documentation, this should be the
expected behavior for callable default values.
If the file duplication behavior described above is needed, this can be
done in a callable and be explained in the documentation.
However, for a callable default value, the type and value of the expected
return value must be precisely defined (in the documentation and perhaps
in the code with some type check and an explicit error message).
To put things in context, I stumbled on this "bug" by migrating our
application to Django 1.8. Some of our image field has a default value
defined in the settings; therefore its value depends on the app deployment
parameters. When examining the migration files generated by Django, I saw
that the default value for these fields was the resolved string value of
the setting, which is not correct for all deployment. The solution was to
change the default value to be a callable that just returns the setting
value. It seemed to work just fine, until we tried to create the object
using a form (like in the admin) where an exception is raised as described
in bug #24823.
Regards,
ymh
--
Ticket URL: <https://code.djangoproject.com/ticket/17224#comment:3>
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 django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/063.b5cebc4b8826c716e8b2e700e22c3937%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
