#28144: Add allow_overwrite kwarg to FileSystemStorage._save
-------------------------------------+-------------------------------------
Reporter: Jon Prindiville | Owner: nobody
Type: New feature | Status: new
Component: File | Version: 1.11
uploads/storage |
Severity: Normal | Resolution:
Keywords: file storage | Triage Stage:
overwrite | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Description changed by Jon Prindiville:
Old description:
> I want to be able to construct a filesystem storage backend that will let
> me overwrite files while still leveraging `FileSystemStorage`.
>
> This set of changes
> (https://github.com/django/django/compare/master...jonprindiville
> :filesystemstorage-allow-overwrite) would enable that without changing
> any of the default behaviour of `FileSystemStorage`. In addition to the
> new kwarg, this adds a test for the existing ''no-overwriting''
> behaviour, and a test for the newly enabled ''overwriting'' behaviour.
>
> I'm not sure about what I should enter here for "Version" (could go in
> anywhere, really) and "Has patch" (I don't have a patch, but I do have a
> PR-able branch, linked above. I am assuming that I should wait for review
> here before actually submitting a PR, though)
>
> === HOW?
>
> Just add an `allow_overwrite` kwarg to `FileSystemStorage._save` that a
> subclasser can optionally take advantage of.
>
> === WHY?
>
> You can't do this in a good way today.
>
> A piece of advice I've seen in several places (see [#refs Refs]) for
> creating an overwriting storage backend is to create a subclass of
> `FileSystemStorage` where the `get_available_name` deletes an existing
> file of the same name. This, in my opinion, is a sneaky use of this
> function, based on the name. I guess it works, but that function is not
> called `get_available_name_and_maybe_delete_some_stuff_also`
>
> A less sneaky (but more race-conditiony) implementation I have seen is to
> have `_save` delete the existing file before calling
> `FileSystemStorage._save`.
>
> One of these is deceptive and one loops forever if you're unlucky.
>
> === [=#refs Refs]:
>
> Various incarnations of this "ovewriting" implementation:
> - django-storages, marked as deprecated (https://github.com/jschneier
> /django-storages/blob/1.5.2/storages/backends/overwrite.py)
> - djangosnippets (https://djangosnippets.org/snippets/976/)
> - someone's gist (https://gist.github.com/fabiomontefuscolo/1584462)
> - django-overwrite-storage (https://github.com/ckot/django-overwrite-
> storage/blob/master/overwrite_storage/storage.py)
New description:
I want to be able to construct a filesystem storage backend that will let
me overwrite files while still leveraging `FileSystemStorage`.
This set of changes
(https://github.com/django/django/compare/master...jonprindiville:ticket_28144)
would enable that without changing any of the default behaviour of
`FileSystemStorage`. In addition to the new kwarg, this adds a test for
the existing ''no-overwriting'' behaviour, and a test for the newly
enabled ''overwriting'' behaviour.
I'm not sure about what I should enter here for "Version" (could go in
anywhere, really) and "Has patch" (I don't have a patch, but I do have a
PR-able branch, linked above. I am assuming that I should wait for review
here before actually submitting a PR, though)
=== HOW?
Just add an `allow_overwrite` kwarg to `FileSystemStorage._save` that a
subclasser can optionally take advantage of.
=== WHY?
You can't do this in a good way today.
A piece of advice I've seen in several places (see [#refs Refs]) for
creating an overwriting storage backend is to create a subclass of
`FileSystemStorage` where the `get_available_name` deletes an existing
file of the same name. This, in my opinion, is a sneaky use of this
function, based on the name. I guess it works, but that function is not
called `get_available_name_and_maybe_delete_some_stuff_also`
A less sneaky (but more race-conditiony) implementation I have seen is to
have `_save` delete the existing file before calling
`FileSystemStorage._save`.
One of these is deceptive and one loops forever if you're unlucky.
=== [=#refs Refs]:
Various incarnations of this "ovewriting" implementation:
- django-storages, marked as deprecated (https://github.com/jschneier
/django-storages/blob/1.5.2/storages/backends/overwrite.py)
- djangosnippets (https://djangosnippets.org/snippets/976/)
- someone's gist (https://gist.github.com/fabiomontefuscolo/1584462)
- django-overwrite-storage (https://github.com/ckot/django-overwrite-
storage/blob/master/overwrite_storage/storage.py)
--
--
Ticket URL: <https://code.djangoproject.com/ticket/28144#comment:1>
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/072.6cbf8d48a1f869b1efc2177775a8347a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
