[Django] #34712: Improve misconfiguration of `STORAGES` setting

2 views
Skip to first unread message

Django

unread,
Jul 15, 2023, 7:01:50 AM7/15/23
to django-...@googlegroups.com
#34712: Improve misconfiguration of `STORAGES` setting
------------------------------------------------+------------------------
Reporter: Bruno Alla | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Documentation | Version: 4.2
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
------------------------------------------------+------------------------
The new `STORAGES` setting added in #26029 is great and super flexible.
While trying to migrate Cookiecutter Django to use it [1], I noticed that
it's quite easy to break the configuration of one of the storages: if I
want to override only one of the 2 default storages (e.g. staticfiles),
then I might be tempted to set:

{{{
STORAGES = {
"staticfiles": {"BACKEND": "MyCustomStorage"},
}
}}}

Which would raise a `InvalidStorageError` when trying to upload a
`FileField` somewhere. AFAIK, nothing warns the user of this
misconfiguration until this point.

I think that one might assume that the dictionary defined by the user
would be "merged" with the default value. I'm assuming that implementing
behaviour could be considered too much of breaking change to the behaviour
etablished in 4.2, but I think the documentation could outline better the
existing behaviour when only one storage is defined by the user.

Another thing that could be maybe be added is a deployment check, to make
sure that both `default` and `staticfiles` storages are present in the
setting.

[1] https://github.com/cookiecutter/cookiecutter-django/pull/4457

--
Ticket URL: <https://code.djangoproject.com/ticket/34712>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

Reply all
Reply to author
Forward
0 new messages