#24041 closed Cleanup/optimization (fixed)
Document effects of saving a model after changing its primary key
Reported by: | Vedant Lath | Owned by: | Helen Sherwood-Taylor |
---|---|---|---|
Component: | Documentation | Version: | 1.7 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
When the value of a primary key field in a record is changed in the admin interface, a new record gets created and the previous record is untouched. This means that the primary key field of a model is effectively read-only and its values cannot be changed.
Steps to reproduce:
- Define a model M as:
class M(models.Model): name = models.CharField(max_length=200, primary_key=True)
- Create a record in M with name as 'ABC' and save it.
- Change the name in the above record to 'XYZ' and save it.
Expected result:
the record 'ABC' is changed to 'XYZ' with an SQL UPDATE command.
Actual result:
a new record 'XYZ' is created and the previous record 'ABC' also exists. No warning or any other message is shown.
If this is intended behaviour, it should be documented appropriately in the primary_key parameter and maybe other places.
Change History (6)
comment:1 by , 9 years ago
Component: | Database layer (models, ORM) → Documentation |
---|---|
Summary: | db.models.base.save() has unexpected behaviour when a primary key field value is changed → Document effects of saving a model after changing its primary key |
Triage Stage: | Unreviewed → Accepted |
Type: | Bug → Cleanup/optimization |
comment:2 by , 9 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:3 by , 9 years ago
PR: https://github.com/django/django/pull/3787
I added docs into both the refs and topics areas. This is a lot of duplication but that is already quite true of those two files. I'm not sure whether this info belongs more in one or the other... or just both.
comment:4 by , 9 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Documentation seems like the way to go as changing the behavior would not only be backward incompatible, but could also require updating ForeignKey constraints.