Thanks for this report. I agree we should detect this change for PKs of auto-created intermediate models.

I tried, I really really tried, but after few days of using different approaches I need to conclude that this is massive, extremely complicate, and maybe even unfeasible. As far as I’m aware we’ve never took into account changes in auto-created many-to-many tables except for those directly related with a definition of ManyToManyFields. A project state used by migrations autodetector doesn’t include auto-created model, so the only fix that I can imagine would require including through_pk_type in the ManyToManyField.deconstruct() but it’s also tricky and error-prone.

We’re going to document this caveat and treat this ticket as a new feature.

​PR with admonition to migrate auto-created through table PKs when changing `DEFAULT_AUTO_FIELD`.

Can we at least provide more detailed migration steps? Right now, the only alternative is to go table by table and do the migration more or less manually. This is very time consuming for large projects.

In 907d3a7:

In bac41697:

A project state used by migrations autodetector doesn’t include auto-created model, so the only fix that I can imagine would require including through_pk_type in the ManyToManyField.deconstruct() but it’s also tricky and error-prone.

That seems like the only solution to me as well.

Having a through_pk: Field(primary_key=True) option instead of through_pk_type seems more flexible though as it would allow easier customization e.g. though_pk=UUIDField(default=uuid.uuid4, primary_key=True). I guess it could also serve as a way to define a composite primary key on the from_field and to_field if we ever manage to add support for that e.g. through_pk=CompositePrimaryKey('author', 'book').