Re: [Django] #34151: Adding explicit primary key with different type doesn't update related ManyToManyFields.

Django

unread,

Nov 11, 2022, 12:14:57 PM11/11/22

to django-...@googlegroups.com

#34151: Adding explicit primary key with different type doesn't update related
ManyToManyFields.
-------------------------------------+-------------------------------------
Reporter: STANISLAV LEPEKHOV | Owner: nobody
Type: Bug | Status: new
Component: Migrations | Version: 4.1
Severity: Normal | Resolution:
Keywords: migrations pk uuid | Triage Stage: Accepted
relation |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Bhuvnesh):

IMO solving [https://code.djangoproject.com/ticket/29574 ticket-29574]
will also solve this issue.

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

Django

unread,

Nov 11, 2022, 12:36:12 PM11/11/22

to django-...@googlegroups.com

#34151: Adding explicit primary key with different type doesn't update related
ManyToManyFields.
-------------------------------------+-------------------------------------
Reporter: STANISLAV LEPEKHOV | Owner: nobody
Type: Bug | Status: new
Component: Migrations | Version: 4.1
Severity: Normal | Resolution:
Keywords: migrations pk uuid | Triage Stage: Accepted
relation |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by STANISLAV LEPEKHOV):

Replying to [comment:4 Mariusz Felisiak]:
Thanks for the comments!
I wanted to note that the problem also occurs for the models.ForeignKey
fields.
The migration succeeds (in the absence of links), and after adding the
link, an exception is thrown.
I apologize in advance for the machine translation =)

Here is the code that will throw the exception:

{{{
class StoreChain(models.Model):
places = models.ManyToManyField(Place, blank=True)

class Place(models.Model):
pass
}}}
if change to this edition (set pk with uuid type) and add relation after:
{{{
class StoreChain(models.Model):
uid = models.UUIDField(default=uuid.uuid4, editable=False,
primary_key=True, unique=True)
place = models.ForeignKey (Place, blank=True, null=True)

class Place(models.Model):
uid = models.UUIDField(default=uuid.uuid4, editable=False,
primary_key=True, unique=True)
}}}

--
Ticket URL: <https://code.djangoproject.com/ticket/34151#comment:6>

Django

unread,

Nov 22, 2022, 2:53:47 PM11/22/22

to django-...@googlegroups.com

#34151: Adding explicit primary key with different type doesn't update related
ManyToManyFields.
-------------------------------------+-------------------------------------

Reporter: STANISLAV LEPEKHOV | Owner: Bhuvnesh
Type: Bug | Status: assigned

Changes (by Bhuvnesh):

* owner: nobody => Bhuvnesh
* status: new => assigned

--
Ticket URL: <https://code.djangoproject.com/ticket/34151#comment:7>

Django

unread,

Nov 23, 2022, 8:24:33 AM11/23/22

to django-...@googlegroups.com

#34151: Adding explicit primary key with different type doesn't update related
ManyToManyFields.
-------------------------------------+-------------------------------------
Reporter: STANISLAV LEPEKHOV | Owner: Bhuvnesh
Type: Bug | Status: assigned
Component: Migrations | Version: 4.1
Severity: Normal | Resolution:
Keywords: migrations pk uuid | Triage Stage: Accepted
relation |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Aravind Swaminathan):

Does this problem occur only while using a uuid field or even with other
type fields as primary key?

--
Ticket URL: <https://code.djangoproject.com/ticket/34151#comment:8>

Django

unread,

Nov 23, 2022, 11:02:47 PM11/23/22

to django-...@googlegroups.com

#34151: Adding explicit primary key with different type doesn't update related
ManyToManyFields.
-------------------------------------+-------------------------------------
Reporter: STANISLAV LEPEKHOV | Owner: Bhuvnesh
Type: Bug | Status: assigned
Component: Migrations | Version: 4.1
Severity: Normal | Resolution:
Keywords: migrations pk uuid | Triage Stage: Accepted
relation |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by STANISLAV LEPEKHOV):

Replying to [comment:8 Aravind Swaminathan]:

> Does this problem occur only while using a uuid field or even with other
type fields as primary key?

I found an error when changing the type to UUID, I did not check with
other types of fields.

--
Ticket URL: <https://code.djangoproject.com/ticket/34151#comment:9>

Django

unread,

Nov 29, 2022, 8:50:12 AM11/29/22

to django-...@googlegroups.com

#34151: Adding explicit primary key with different type doesn't update related
ManyToManyFields.
-------------------------------------+-------------------------------------
Reporter: STANISLAV LEPEKHOV | Owner: Bhuvnesh
Type: Bug | Status: assigned
Component: Migrations | Version: 4.1
Severity: Normal | Resolution:
Keywords: migrations pk uuid | Triage Stage: Accepted
relation |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Bhuvnesh):

The migration generated for this contains removing the old pk and adding
new pk :
{{{
class Migration(migrations.Migration):

dependencies = [
("ticket_34151", "0001_initial"),
]

operations = [
migrations.RemoveField(
model_name="place",
name="id",
),
migrations.RemoveField(
model_name="storechain",
name="id",
),
migrations.AddField(
model_name="place",
name="uid",
field=models.UUIDField(
default=uuid.uuid4,
editable=False,
primary_key=True,
serialize=False,
unique=True,
),
),
migrations.AddField(
model_name="storechain",
name="uid",
field=models.UUIDField(
default=uuid.uuid4,
editable=False,
primary_key=True,
serialize=False,
unique=True,
),
),
]
}}}
but on some databases (mysql, postgres) we cannot delete a pk of a model
which is referenced by other.
I tried to implement a
solution([https://github.com/django/django/pull/16325 draft PR] ) which is
working fine for sqlite3 but throws the following error on some dbs
(mysql, postgres) during the RemoveField operation:
{{{
(1829, "Cannot drop column 'id': needed in a foreign key constraint
'ticket_34151_storech_placespk_id_ca7ce831_fk_ticket_34' of table
'ticket_34151_storechain'")
}}}
This made me think if it is really possible to add a new pk to a
referenced model for dbs like mysql and postgres?

--
Ticket URL: <https://code.djangoproject.com/ticket/34151#comment:10>

Django

unread,

Feb 13, 2023, 9:37:15 AM2/13/23

to django-...@googlegroups.com

#34151: Adding explicit primary key with different type doesn't update related
ManyToManyFields.
-------------------------------------+-------------------------------------
Reporter: STANISLAV LEPEKHOV | Owner: Bhuvnesh
Type: Bug | Status: assigned
Component: Migrations | Version: 4.1
Severity: Normal | Resolution:
Keywords: migrations pk uuid | Triage Stage: Accepted
relation |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Bhuvnesh):

STANISLAV, With a default uuid value you cannot insert previous values of
id in the new table ? So you can only change pk to uuid field when the db
is empty ? Correct me if i'm wrong.

--
Ticket URL: <https://code.djangoproject.com/ticket/34151#comment:11>

Django

unread,

Feb 14, 2023, 11:20:11 AM2/14/23

to django-...@googlegroups.com

#34151: Adding explicit primary key with different type doesn't update related
ManyToManyFields.
-------------------------------------+-------------------------------------
Reporter: STANISLAV LEPEKHOV | Owner: Bhuvnesh
Type: Bug | Status: assigned
Component: Migrations | Version: 4.1
Severity: Normal | Resolution:
Keywords: migrations pk uuid | Triage Stage: Accepted
relation |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by STANISLAV LEPEKHOV):

Replying to [comment:11 Bhuvnesh]:

> STANISLAV, With a default uuid value you cannot insert previous values
of id in the new table ? So you can only change pk to uuid field when the
db is empty ? Correct me if i'm wrong.

The essence of the problem is that I cannot correctly change the DATA TYPE
for the pk field (including with an empty database). If I have an integer
data type and there is a m2m field in another model containing pk of these
objects, then when changing the data type to uuid, there will be no
changes in the m2m table after migration (the type int, int will remain
there)

--
Ticket URL: <https://code.djangoproject.com/ticket/34151#comment:12>

Django

unread,

Feb 15, 2023, 1:31:53 PM2/15/23

to django-...@googlegroups.com

#34151: Adding explicit primary key with different type doesn't update related
ManyToManyFields.
-------------------------------------+-------------------------------------

Reporter: STANISLAV LEPEKHOV | Owner: (none)
Type: Bug | Status: new

Changes (by Bhuvnesh):

* owner: Bhuvnesh => (none)
* status: assigned => new

Comment:

OK, so i did some more work on this and found that it is much more
complicated than i thought it would be:

1. You CANNOT switch pk field type if you already have some data in it
without custom operations.
2. the naive solution could be to remake all the tables that are
referencing to a model's pk but even that is not possible in MySql as we
cannot drop a table if it is referenced by other table.(throws error in
case when 2 models are related to each other)
3. the only solution i can think of (and tried) is deleting all related
models and then recreating them with new uid field.

So i'm deassigning myself in case someone has a better solution.

--
Ticket URL: <https://code.djangoproject.com/ticket/34151#comment:13>

Django

unread,

Mar 11, 2023, 1:41:20 PM3/11/23

to django-...@googlegroups.com

#34151: Adding explicit primary key with different type doesn't update related
ManyToManyFields.
-------------------------------------+-------------------------------------

Reporter: STANISLAV LEPEKHOV | Owner: Ayush
| Bisht
Type: Bug | Status: assigned

Changes (by Ayush Bisht):

* owner: (none) => Ayush Bisht

* status: new => assigned

--
Ticket URL: <https://code.djangoproject.com/ticket/34151#comment:14>

Django

unread,

Apr 29, 2023, 1:37:55 AM4/29/23

to django-...@googlegroups.com

#34151: Adding explicit primary key with different type doesn't update related
ManyToManyFields.
-------------------------------------+-------------------------------------

Reporter: STANISLAV LEPEKHOV | Owner: Priyank
| Panchal

Changes (by Priyank Panchal):

* owner: Ayush Bisht => Priyank Panchal

--
Ticket URL: <https://code.djangoproject.com/ticket/34151#comment:15>

Django

unread,

May 8, 2023, 7:04:00 AM5/8/23

to django-...@googlegroups.com

#34151: Adding explicit primary key with different type doesn't update related
ManyToManyFields.
-------------------------------------+-------------------------------------
Reporter: STANISLAV LEPEKHOV | Owner: Priyank
| Panchal
Type: Bug | Status: assigned
Component: Migrations | Version: 4.1
Severity: Normal | Resolution:
Keywords: migrations pk uuid | Triage Stage: Accepted
relation |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Changes (by Sarah Abderemane):

* cc: Sarah Abderemane (added)

--
Ticket URL: <https://code.djangoproject.com/ticket/34151#comment:16>

Django

unread,

Aug 16, 2023, 8:11:58 AM8/16/23

to django-...@googlegroups.com

#34151: Adding explicit primary key with different type doesn't update related
ManyToManyFields.
-------------------------------------+-------------------------------------

Reporter: STANISLAV LEPEKHOV | Owner: (none)
Type: Bug | Status: new

Changes (by Priyank Panchal):

* owner: Priyank Panchal => (none)

* status: assigned => new

--
Ticket URL: <https://code.djangoproject.com/ticket/34151#comment:17>

Django

unread,

Feb 26, 2024, 11:38:01 PM2/26/24

to django-...@googlegroups.com

#34151: Adding explicit primary key with different type doesn't update related
ManyToManyFields.
-------------------------------------+-------------------------------------

Reporter: STANISLAV LEPEKHOV | Owner: Akash
| Kumar Sen
Type: Bug | Status: assigned

Changes (by Akash Kumar Sen):

* owner: (none) => Akash Kumar Sen

* status: new => assigned

--
Ticket URL: <https://code.djangoproject.com/ticket/34151#comment:18>

Django

unread,

Mar 13, 2026, 12:31:58 PMMar 13

to django-...@googlegroups.com

#34151: Adding explicit primary key with different type doesn't update related
ManyToManyFields.
-------------------------------------+-------------------------------------

Reporter: STANISLAV LEPEKHOV | Owner: Carol
| Naranjo

Changes (by Carol Naranjo):

* owner: Akash Kumar Sen => Carol Naranjo

--
Ticket URL: <https://code.djangoproject.com/ticket/34151#comment:19>

Django

unread,

Mar 15, 2026, 7:02:17 AMMar 15

to django-...@googlegroups.com

#34151: Adding explicit primary key with different type doesn't update related
ManyToManyFields.
-------------------------------------+-------------------------------------
Reporter: STANISLAV LEPEKHOV | Owner: Carol
| Naranjo
Type: Bug | Status: assigned
Component: Migrations | Version: 4.1
Severity: Normal | Resolution:
Keywords: migrations pk uuid | Triage Stage: Accepted
relation |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Carol Naranjo):

STANISLAV I know this is old, but I could not replicate the issue by just
altering the PK type. At least in my test with sqlite I see the many-to-
many table updated as expected. Can you specify with which DB did you
encountered the issue?

Here is what I tried.

1. Initial setup with initial models (tables already existing in DB but
with empty rows):

{{{
class Place(models.Model):
pass

class StoreChain(models.Model):
pass
places = models.ManyToManyField(Place, blank=True)

}}}

2. Update models

{{{
class Place(models.Model):
id = models.UUIDField(default=uuid.uuid4, editable=False,
primary_key=True)

class StoreChain(models.Model):
id = models.UUIDField(default=uuid.uuid4, editable=False,
primary_key=True)
places = models.ManyToManyField(Place, blank=True)
}}}

3. `makemigrations` and `migrate` ==> I see all 3 tables updated with the
migration file generated as follows:

{{{

import uuid
from django.db import migrations, models

class Migration(migrations.Migration):

dependencies = [
('store', '0001_initial'),
]

operations = [
migrations.AlterField(

model_name='place',
name='id',

field=models.UUIDField(default=uuid.uuid4, editable=False,
primary_key=True, serialize=False),
),
migrations.AlterField(

model_name='storechain',
name='id',

field=models.UUIDField(default=uuid.uuid4, editable=False,
primary_key=True, serialize=False),
),
]

}}}

However, if I try renaming the column as well the migration file will be
generated with RemoveField and AddField which at least with my setup using
sqlite is causing another error when applying the migration, hoewever I
would track that new finding as a separate issue in another ticket.
--
Ticket URL: <https://code.djangoproject.com/ticket/34151#comment:20>

Django

unread,

Mar 15, 2026, 2:17:38 PMMar 15

to django-...@googlegroups.com

#34151: Adding explicit primary key with different type doesn't update related
ManyToManyFields.
-------------------------------------+-------------------------------------
Reporter: STANISLAV LEPEKHOV | Owner: Carol
| Naranjo
Type: Bug | Status: assigned
Component: Migrations | Version: 4.1
Severity: Normal | Resolution:
Keywords: migrations pk uuid | Triage Stage: Accepted
relation |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by ai-da-stas):

Hi! I used:

PostgreSQL + Django 4.0.3 + psycopg2-binary 2.9.1
--
Ticket URL: <https://code.djangoproject.com/ticket/34151#comment:21>

Django

unread,

Mar 23, 2026, 8:04:42 AMMar 23

to django-...@googlegroups.com

#34151: Adding explicit primary key with different type doesn't update related
ManyToManyFields.
-------------------------------------+-------------------------------------
Reporter: STANISLAV LEPEKHOV | Owner: Carol
| Naranjo
Type: Bug | Status: assigned
Component: Migrations | Version: 4.1
Severity: Normal | Resolution:
Keywords: migrations pk uuid | Triage Stage: Accepted
relation |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Carol Naranjo):

Thanks for the details. I was able to reproduce the exact issue in older
versions of Django (including the reported 4.0.3), psycopg2-binary 2.9.11,
and the latest PostgreSQL (18.3 as of today). Here are my findings:

**Behavior with Django 4.0.3 to 5.2.12:**
I confirmed that in these versions, the migration proceeds but results in
an inconsistent database state: The relationship table is not updated to
match the new primary key type and the foreign key is dropped in the many-
to-many table.

**Behavior with Django >= 6.0:**
I tested the same scenario in the latest versions (6.0 and 6.1-dev), and
the behavior has changed significantly. Instead of a silent failure when
attempting to run this particular migration (which generates RemoveField
and AddField operations for the primary key change), the database now
explicitly blocks the destructive operation with an **InternalError**:
{{{
# (0.003) ALTER TABLE "issue34151_place" DROP COLUMN "id"; args=None;
alias=default
# ...
# django.db.utils.InternalError: cannot drop column id of table
issue34151_place
# because other objects depend on it
# DETAIL: constraint issue34151_storechain_place_id_97554049_fk_issue3415
on
# table issue34151_storechain_places depends on column id of table
issue34151_place
# HINT: Use DROP ... CASCADE to drop the dependent objects too.
}}}

This is, in my opinion, the correct and expected behavior. By triggering a
database-level error, Django prevents the creation of the 'broken' state
described in the original report so **I recommend closing this ticket** as
the behavior in the latest mainstream-supported versions is consistent
with expected database integrity standards.

**Additional Information / Hints for Users**
In order to perform this type of migration (changing both the name and
type of a primary key), here are a few considerations:

- **Manual Migration Steps**: An alternative way to apply this change
would be writing a migration with RenameField and AlterType operations.
However, be aware that for this specific example, PostgreSQL would still
fail to cast a BigInt directly into a UUID. This is a database-level
requirement for explicit casting, not a bug in Django. If for example the
type was altered to a compatible format (such as a string/VarChar) instead
of a UUID, the operation would execute correctly as expected.

- **The Limits of Automated Migration Generation**: Django migrations
provide a 'best guess' of the operations required to keep tables and
relationships consistent. However, according to the documentation ''“some
of the more complex operations are not autodetectable and are only
available via a hand-written migration”'' (See
[https://docs.djangoproject.com/en/6.0/topics/migrations/#migration-files
link] ) . When these limitations are hit, manual migration adjustments are
the standard procedure.
--
Ticket URL: <https://code.djangoproject.com/ticket/34151#comment:22>

Django

unread,

Apr 22, 2026, 5:59:33 AMApr 22

to django-...@googlegroups.com

#34151: Adding explicit primary key with different type doesn't update related
ManyToManyFields.
-------------------------------------+-------------------------------------
Reporter: STANISLAV LEPEKHOV | Owner: Carol
| Naranjo
Type: Bug | Status: assigned
Component: Migrations | Version: 4.1
Severity: Normal | Resolution:
Keywords: migrations pk uuid | Triage Stage: Accepted
relation |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Carol Naranjo):

Closing the ticket as it is not relevant anymore as discussed in the
previous comment.
--
Ticket URL: <https://code.djangoproject.com/ticket/34151#comment:23>

Django

unread,

Apr 22, 2026, 6:00:07 AMApr 22

to django-...@googlegroups.com

#34151: Adding explicit primary key with different type doesn't update related
ManyToManyFields.
-------------------------------------+-------------------------------------
Reporter: STANISLAV LEPEKHOV | Owner: Carol
| Naranjo

Type: Bug | Status: closed
Component: Migrations | Version: 4.1
Severity: Normal | Resolution: fixed

Changes (by Carol Naranjo):

* resolution: => fixed
* status: assigned => closed

--
Ticket URL: <https://code.djangoproject.com/ticket/34151#comment:24>

Django

unread,

Apr 22, 2026, 6:24:26 AMApr 22

to django-...@googlegroups.com

#34151: Adding explicit primary key with different type doesn't update related
ManyToManyFields.
-------------------------------------+-------------------------------------
Reporter: STANISLAV LEPEKHOV | Owner: Carol
| Naranjo

Type: Bug | Status: new

Component: Migrations | Version: 4.1
Severity: Normal | Resolution:

Changes (by Jacob Walls):

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

Comment:

Hi Carol, thanks for the triage. Did you bisect the behavior change to a
specific commit? I tried to check your triage result, but when running the
changes described in comment:20, I get `AlterField` & `AlterField` as
described there, not `RemoveField` & `AlterField` as described in
comment:22. Also, I see no difference all the way back to 4.2. Let's keep
this open until someone else can confirm your triage.
--
Ticket URL: <https://code.djangoproject.com/ticket/34151#comment:25>

Django

unread,

Apr 22, 2026, 11:34:20 AMApr 22

to django-...@googlegroups.com

#34151: Adding explicit primary key with different type doesn't update related
ManyToManyFields.
-------------------------------------+-------------------------------------

Reporter: STANISLAV LEPEKHOV | Owner: (none)
Type: Bug | Status: assigned

* owner: Carol Naranjo => (none)

* status: new => assigned

--
Ticket URL: <https://code.djangoproject.com/ticket/34151#comment:26>

Django

unread,

Apr 22, 2026, 11:34:25 AMApr 22

to django-...@googlegroups.com

#34151: Adding explicit primary key with different type doesn't update related
ManyToManyFields.
-------------------------------------+-------------------------------------
Reporter: STANISLAV LEPEKHOV | Owner: (none)

Type: Bug | Status: new

* status: assigned => new

--
Ticket URL: <https://code.djangoproject.com/ticket/34151#comment:27>

Django

unread,

Apr 24, 2026, 6:42:09 AMApr 24

to django-...@googlegroups.com

#34151: Adding explicit primary key with different type doesn't update related
ManyToManyFields.
-------------------------------------+-------------------------------------
Reporter: STANISLAV LEPEKHOV | Owner: (none)
Type: Bug | Status: new
Component: Migrations | Version: 4.1
Severity: Normal | Resolution:
Keywords: migrations pk uuid | Triage Stage: Accepted
relation |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Carol Naranjo):

Hi Jacob, let me clarify. The result in comment:22 is not by applying the
changes in comment:20, but rather by applying the changes in the original
report and in comment:6. (comment:20 was only my alternative attempt to
reproduce the issue when I didn't know which database was used).

That is, the issue before django 6.0 was when changing both field type AND
name in 1 step, which will result in a database in an inconsistent state
regarding the foreign keys.

After django 6.0 the migration script is the same, but the execution will
fail, which will at least leave the database in a consistent state.
--
Ticket URL: <https://code.djangoproject.com/ticket/34151#comment:28>

Django

unread,

Apr 24, 2026, 6:53:20 AMApr 24

to django-...@googlegroups.com

#34151: Adding explicit primary key with different type doesn't update related
ManyToManyFields.
-------------------------------------+-------------------------------------
Reporter: STANISLAV LEPEKHOV | Owner: (none)
Type: Bug | Status: new
Component: Migrations | Version: 4.1
Severity: Normal | Resolution:
Keywords: migrations pk uuid | Triage Stage: Accepted
relation |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Carol Naranjo):

Maybe a more accurate but verbose title for this issue would be
"Inconsistent DB state after applying a migration that failed silently:

Adding explicit primary key with different type doesn't update related
ManyToManyFields."

---

Furthermore, and at this point this is not regarding this specific issue.
While investigating the current one and testing with sqlite I faced the
issue that I later described in the ticket #37006. For which I opened this
PR [https://github.com/django/django/pull/21073] and is waiting a second
review round. In that PR, the autodetector will recognize the alter
operations instead of the recreation, so if merged, that PR will also
avoid running into this issue in the first place.
--
Ticket URL: <https://code.djangoproject.com/ticket/34151#comment:29>

Reply all

Reply to author

Forward