2020 edition of core.files.storages.Storage.copy method

[Lorenzo Peña]

Hi everyone!

About providing an interface 'copy' method for file storages, is this still no-go as of 2020?

Background reading:

- https://github.com/jschneier/django-storages/issues/428

- https://code.djangoproject.com/ticket/20488

- https://github.com/django/django/pull/4244

Thanks!

[Carlton Gibson]

Hi Lorenzo. 

You’re asking folks to do quite a lot of homework there. 

Any chance you could summarise the previous discussions and explain at least, why this might be a good feature, and why (presumably) it was a no-go last time? 

I think there’s more chance of positive input that way. 🙂

Kind Regards,

Carlton

--
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-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/72b014cf-fcd7-41d2-af86-c90248b6ff19n%40googlegroups.com.

[Lorenzo Peña]

Apologies for the lazy version. Let me elaborate a bit more :)

From what I read, the blocker last time was a lack of a clear path in how to handle a "file already exists" type of error. [1]

In my case, the need for a 'copy' method arose from a two step upload flow: first step is to upload the file to a temporary location, second step is to confirm the upload and move the file to its permanent location (defined by some model's field.) If the 'copy' interface is provided at the storage level, it will help abstract away the specific storage implementation, and for some storage classes, it could perfectly raise an exception (if such behavior makes no sense for that class).

As of now, every time I need to 'move' a file from one location to another, while still using Django provided APIs, I have to go through the currently provided open/save API, which makes the length of the file go through the Django processes (again), which I consider to be a needless burden (perhaps I'm wrong here.)

The middle ground alternative is to subclass each storage I want to use and provide a 'copy' implementation for those. This is okay. Now, can we reconsider lifting that up to the Django codebase itself? 

Hope this sheds some light in the request.

Thanks!

References:

[1] https://github.com/django/django/pull/4244#discussion_r29055386

[Lorenzo Peña]

Some extra context: in  https://docs.djangoproject.com/en/3.1/topics/files/ there is a code example that uses `os.rename`. I consider this behavior to be needed quite often on some scenarios, except that the specific implementation of `rename` will depend on the storage being used.

[Adam Johnson]

From what I can see in the original PR, it was closed fairly quickly by the author, without debate.

I think the option of using FileExistsError for pre-existing files, even on "non-OS filesystems" like S3, is fine. At the end of the day there's an operating system somewhere, and it's better than ValueError or inventing a new exception class.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/23bf1af9-0b62-473e-bde1-48b18317be3bn%40googlegroups.com.

--

Adam