Hello,
the current Storage API has some inconsistencies and in short it's impossible
to write
anything that requires a directory to be made (if storage is FileSystemStorage)
in an
implementation agnostic way.
Aside from that, there's a listdir() method that only makes sense in a
FileSystemStorage based implementation (DB storage could emulate it, but it
isn't
natural).
So, I had two ideas to fix it and would like to know developer preference
before filing a
PR:
1. Remove FileSystemStorage API's from Storage (specifically listdir) and
make
save() do all the work to save the file, where the only acceptable failures are
outside
Django's control (read-only mounts, (table-)space issues, etc)
2. Change listdir() to list_container and add methods that handle Storage
containers: abstract things that hold the file. save() either deligates to
container
methods or requires that container exists before saving.
The use case that prompted this was that I've created an ImageField subclass
that
generates thumbnails in model-specified sizes and puts them in directories
below the
one of the current image (named widthxheight, f.e. 64x64). In doing so I had to
go
outside FieldFile.storage to have the intermediate directory created, so my
code now
isn't portable to different Storage subclasses.
Is there any interest in either of these (another?) approach and if so, what
preference?
--
Melvyn Sopacua
--
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/1599056.lNnDFJ18CA%40devstation.
For more options, visit https://groups.google.com/d/optout.
