Right now, we end up with tables that have FKs as bigint, but their own PK
as integer. This may not be a direct bug, but will cause issues for sure.
Ideally, ManyToManyField should have an easy way to configure its PK
without having to implement the `through` model.
--
Ticket URL: <https://code.djangoproject.com/ticket/32674>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* severity: Normal => Release blocker
* cc: Tom Forbes (added)
* component: Uncategorized => Migrations
* easy: 1 => 0
* type: Uncategorized => Bug
* stage: Unreviewed => Accepted
Comment:
Thanks for this report. I agree we should detect this change for PKs of
auto-created intermediate models.
--
Ticket URL: <https://code.djangoproject.com/ticket/32674#comment:1>
* cc: Simon Charette, Andrew Godwin, Shai Berger, Markus Holtermann
(added)
* version: 3.2 => 4.0
* type: Bug => New feature
* severity: Release blocker => Normal
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/32674#comment:2>
Comment (by Carlton Gibson):
[https://github.com/django/django/pull/14328 PR with admonition to migrate
auto-created through table PKs when changing `DEFAULT_AUTO_FIELD`].
--
Ticket URL: <https://code.djangoproject.com/ticket/32674#comment:3>
Comment (by cristianoccazinsp):
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/32674#comment:4>
Comment (by Carlton Gibson <carlton.gibson@…>):
In [changeset:"907d3a7ff4e12ad4ccc86af26a728007fe4d6fa2" 907d3a7]:
{{{
#!CommitTicketReference repository=""
revision="907d3a7ff4e12ad4ccc86af26a728007fe4d6fa2"
Refs #32674 -- Noted that auto-created through table PKs cannot be
automatically migrated.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/32674#comment:5>
Comment (by Carlton Gibson <carlton.gibson@…>):
In [changeset:"bac416972df546ac58febd3990b2107d60d7f166" bac41697]:
{{{
#!CommitTicketReference repository=""
revision="bac416972df546ac58febd3990b2107d60d7f166"
[3.2.x] Refs #32674 -- Noted that auto-created through table PKs cannot be
automatically migrated.
Backport of 907d3a7ff4e12ad4ccc86af26a728007fe4d6fa2 from main
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/32674#comment:6>
Comment (by Simon Charette):
> 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')`.
--
Ticket URL: <https://code.djangoproject.com/ticket/32674#comment:7>
* cc: אורי (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/32674#comment:8>