[Django] #32464: Enable "detaching" of file from FileField and ImageField

36 views
Skip to first unread message

Django

unread,
Feb 19, 2021, 1:51:30 PM2/19/21
to django-...@googlegroups.com
#32464: Enable "detaching" of file from FileField and ImageField
-------------------------------------+-------------------------------------
Reporter: Samuli- | Owner: nobody
Petrus Korhonen |
Type: New | Status: new
feature |
Component: Database | Version: 3.1
layer (models, ORM) |
Severity: Normal | Keywords:
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
When model contains FileField (or ImageField) cloning an instance by
setting primarykey to None and saving object leads to problems. It seems
that the resulting objects refer to same file which is not the desired
behaviour as this leads to invalid objects.

It would make sense to have facility to "detach" FileField from file
without deleting the actual file. After taking a look at the FieldFile
code I think this functionality would be trivial to add and I would be
happy to submit a pull request implementing this feature if it has
sufficient merit to be merged.

Also, I would like to have feedback on whether maintainers prefer a
separate "detach" function or if it should be implemented as parameter on
"delete".

PS. I could also implement "attach" function if there is need for it.

--
Ticket URL: <https://code.djangoproject.com/ticket/32464>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

Django

unread,
Mar 2, 2021, 5:04:26 AM3/2/21
to django-...@googlegroups.com
#32464: Enable "detaching" of file from FileField and ImageField
-------------------------------------+-------------------------------------
Reporter: Samuli-Petrus | Owner: nobody
Korhonen |
Type: New feature | Status: closed
Component: Database layer | Version: 3.1
(models, ORM) |
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0

Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Carlton Gibson):

* status: new => closed
* resolution: => wontfix


Comment:

Hi.

> ...cloning an instance by setting primarykey to None and saving object


leads to problems. It seems that the resulting objects refer to same file
which is not the desired behaviour as this leads to invalid objects.

This strikes me as a special case of a much harder problem — you're going
to get the same issue come up for any reference the model might hold. The
[https://docs.djangoproject.com/en/3.1/topics/db/queries#copying-model-
instances copying model instances] docs already hint at the issue: more-
or-less you need to reset (or provide your own logic for) any fields for
which the naive **Use the same value** isn't appropriate.

See #4027 for discussion about **not** including such more complex logic
in Django.

I think there have been various takes on this issue over the years.
[https://github.com/tj-django/django-clone django-clone] looks to be one
that is currently maintained.

I'm closing as `wontfix` but if you wanted to see if anyone on the
DevelopersMailingList thinks this could be do-able, that would be OK. The
conclusion from #4027 was roughly that per-project logic is relatively
simple, but that a generic solution is almost impossible, so that it's not
worth the complexity in core, but maybe that can be reviewed.

Thanks.

--
Ticket URL: <https://code.djangoproject.com/ticket/32464#comment:1>

Reply all
Reply to author
Forward
0 new messages