I'd like to introduce a file storage registry similar to
BaseConnectionHandler (django/utils/connection.py) and EngineHandler
(django/template/utils.py).
Example settings.py snippet:
STORAGES = { # rename to FILE_STORAGES to make it more explictit?
'example': {
'BACKEND': 'django.core.files.storage.FileSystemStorage',
'OPTIONS': {
'location': '/example',
'base_url': '/example/',
},
},
}
Changes introduced by this pr are backward compatible. Users can still use
existing settings to configure static and media storages.
Currently storages can be retrieved from the following objects:
django/core/files/storage.py:
get_storage_class
DefaultStorage
default_storage
django/contrib/staticfiles/storage.py:
ConfiguredStorage
staticfiles_storage
What do you think about deprecating them?
https://github.com/django/django/pull/15610
FileField can be tackled in a separate pr.
czwartek, 12 listopada 2015 o 11:25:57 UTC+1 ja...@tartarus.org napisał(a):
> On 8 Nov 2015, at 08:31, Marc Tamlyn <marc....@gmail.com> wrote:
>
> > I'm definitely in favour of a format allowing multiple storage back ends
> referred to by name. For larger sites it is not unusual to manage files
> across multiple locations (eg several S3 buckets). The storage param to
> FileField would be allowed to be the key, and there would be a get_storage
> function like get_cache.
>
> It would remove the assymetry between the default backends and per-field
> ones, which does feel a little odd. However I don’t think that’s a strong
> enough reason to go for more complicated. Ballooning dictionaries can feel
> overwhelming when looking at modern Django settings (for instance, the new
> templates configuration is more daunting than it used to be), and as
> pointed out, overriding is more fiddly.
>
> For testing, you need to be explicit per-field no matter what, so it’s a
> change from an instance to a symbolic reference. The instance is probably a
> variable anyway by declaration of the test model, which I suspect is
> slightly easier to chase.
>
> So I’d be slightly more in favour of the terse, tuple-based syntax.
>
> J
>
> --
> James Aylett
> I make: devfort.com, spacelog.org
> Films: talktorex.co.uk
> Everything else: tartarus.org/james/
>
>
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/7b11a017-b1c9-4277-aa1f-fb3b8a26ae18n%40googlegroups.com.
