Opened 6 years ago
Last modified 8 months ago
#29790 new Bug
Release notes / Changelog missing information about change in duplicate pk behaviour in 2.1 — at Initial Version
Reported by: | Richard Ebeling | Owned by: | nobody |
---|---|---|---|
Component: | Migrations | Version: | 2.1 |
Severity: | Normal | Keywords: | multiple primary keys migration id uuid |
Cc: | karyon, Richard Ebeling, Tim Martin, Ülgen Sarıkavak | Triage Stage: | Accepted |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
We migrated a model from a AutoField as id (default behaviour) to a UUIDField in the past, using a migration that looked like this with django 2.0:
https://code.djangoproject.com/ticket/28541
There was a bug in SQLite though, which as of today only has the workaround listed in the bug tracker: https://code.djangoproject.com/ticket/28541
Thus, we ended up writing our migration like this: https://github.com/fsr-itse/EvaP/blob/master/evap/evaluation/migrations/0062_replace_textanswer_id_with_uuid.py
When we try updating to django 2.1 now, this migration fails whenever you call migrate with the error
django.db.utils.ProgrammingError: multiple primary keys for table "evaluation_textanswer" are not allowed
It works if we add a RemoveField instruction for the old id before setting primary_key=True
on the new UUIDField. But this will trigger the SQLite bug listed above. Changing the old AutoField to primary_key=False
where the RemoveField instruction would be doesn't fix the error.
The documentation states that a object may not have more than one primary key here: https://docs.djangoproject.com/en/2.0/ref/models/fields/#django.db.models.Field.primary_key
Still, in the release notes for django 2.1 it should be noted that django's behaviour was changed here. Also, I would appreciate if there was some kind of documentation on how you should migrate primary keys from a field to another if no two primary keys are allowed in between. There should be a way without squashing the migrations as we want to keep the history.