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 El miércoles, 2 de septiembre de 2020 a las 11:16:36 UTC-4, [email protected] escribió: > 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 > > > On 2 Sep 2020, at 16:59, Lorenzo Peña <[email protected]> wrote: > > 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! > > -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/72b014cf-fcd7-41d2-af86-c90248b6ff19n%40googlegroups.com > > <https://groups.google.com/d/msgid/django-developers/72b014cf-fcd7-41d2-af86-c90248b6ff19n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/69320627-3bb3-4874-9ea9-e18794ef8013n%40googlegroups.com.
