Changes between Initial Version and Version 1 of Ticket #29790


Ignore:
Timestamp:
Sep 25, 2018, 11:02:43 AM (6 years ago)
Author:
Tim Graham
Comment:

It's unclear if the behavior change was intentional. Can you provide a sample project and ​bisect to find the commit where the behavior changed?

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #29790

    • Property Summary Release notes / Changelog missing information about change in duplicate pk behaviour in 2.1 → Release notes missing information about change in duplicate pk behavior in 2.1

  • Ticket #29790 – Description

    initial v1  
    11We 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:
    2 https://code.djangoproject.com/ticket/28541
     2#28541
    33
    4 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
     4There was a bug in SQLite though, which as of today only has the workaround listed in the bug tracker: #28541
    55
    66Thus, 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
    … …  
    1111It 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.
    1212
    13 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
     13The documentation states that [https://docs.djangoproject.com/en/stable/ref/models/fields/#django.db.models.Field.primary_key an object may not have more than one primary key].
    1414
    15 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.
     15Still, in the release notes for django 2.1 it should be noted that django's behavior 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.
Back to Top