#34242 closed Cleanup/optimization (fixed)
Behavior of Model.delete() with regards to primary_key fields is not documented
Reported by: | SwampFalc | Owned by: | noFFENSE |
---|---|---|---|
Component: | Documentation | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Ready for checkin | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | yes | UI/UX: | no |
Description
When .delete() is called on a model instance, the primary_key field of that instance is set to None (https://github.com/django/django/blob/main/django/db/models/deletion.py#L456).
For a "standard" autoincrement PK, this is fine. However, if you have defined an actual data field as primary_key on the model, this data is lost in the instance.
This is counter to what is stated in the basic documentation about "Deleting objects" (https://docs.djangoproject.com/en/4.1/ref/models/instances/#deleting-objects): "This only deletes the object in the database; the Python instance will still exist and will still have data in its fields."
There is also no mention of this in the documentation of "primary_key" (https://docs.djangoproject.com/en/4.1/ref/models/fields/#primary-key) or the more in-depth documentation about "Deleting objects" (https://docs.djangoproject.com/en/4.1/topics/db/queries/#deleting-objects).
I feel that this should at the very least be mentioned in the "primary_key" documentation, perhaps in some of the other locations too.
If an agreement can be reached about where it should be mentioned and where not, I am willing to create a pull request.
Change History (13)
comment:1 by , 23 months ago
comment:2 by , 23 months ago
Triage Stage: | Unreviewed → Accepted |
---|
I think something as small as... "the Python instance will still exist and will still have data in its fields, but the primary key is set to None
" in the Deleting objects docs you point to, would likely be enough.
You know, thinking about it some more... What exactly is the reason for setting the PK to None upon deletion? Is that really necessary?
Standardly, whether the object has a PK is the test whether it's been saved (i.e. exists in the DB). I doubt that's changeable.
(Others may give a better account.)
comment:3 by , 22 months ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:4 by , 22 months ago
Has patch: | set |
---|
comment:5 by , 22 months ago
Triage Stage: | Accepted → Ready for checkin |
---|
comment:6 by , 22 months ago
Please, tell me if something is wrong, and I will fix it, that's only my 2nd contribution, so I do not know whether I did a good job or not
follow-up: 8 comment:7 by , 22 months ago
Triage Stage: | Ready for checkin → Accepted |
---|
Please don't mark your own PRs as "Ready for checkin".
comment:8 by , 22 months ago
Replying to Mariusz Felisiak:
Please don't mark your own PRs as "Ready for check-in".
Okay, may I ask why?
comment:9 by , 22 months ago
Have a read of the Triage Workflow docs — they explain the process.
(Basically, someone else needs to review your patch first.)
comment:10 by , 22 months ago
Triage Stage: | Accepted → Ready for checkin |
---|
You know, thinking about it some more... What exactly is the reason for setting the PK to None upon deletion? Is that really necessary?
Should it perhaps only happen when the PK is an autoincrement? Or should it perhaps not happen at all?