[Django] #36803: Make AlterField a no-op when ManyToManyField's through.db_table remains the same between renames.

[Django]

#36803: Make AlterField a no-op when ManyToManyField's through.db_table remains the
same between renames.
-------------------------------------+-------------------------------------
Reporter: Clifford | Owner: Clifford Gama
Gama |
Type: | Status: assigned
Cleanup/optimization |
Component: Database | Version: 6.0
layer (models, ORM) | Keywords: AlterField, no-op,
Severity: Normal | ManyToManyField
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
[https://github.com/django/django/pull/20412#issue-3732276360 As suggested
by Simon]. Similar to f05cc5e3d2ae7663dbd248029bcb74500cf1029f (for
`db_table` on foreign keys) and #31825 for `db_column`s.
--
Ticket URL: <https://code.djangoproject.com/ticket/36803>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

[Django]

#36803: Make AlterField a no-op when ManyToManyField's through.db_table remains the
same between renames.
-------------------------------------+-------------------------------------

Reporter: Clifford Gama | Owner: Clifford
Type: | Gama
Cleanup/optimization | Status: assigned
Component: Migrations | Version: 6.0
Severity: Normal | Resolution:
Keywords: AlterField, no-op, | Triage Stage:
ManyToManyField | Unreviewed
Has patch: 0 | Needs documentation: 0

Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Changes (by Jacob Walls):

* component: Database layer (models, ORM) => Migrations

Comment:

Thanks. #33197 is another similar fixed ticket.
--
Ticket URL: <https://code.djangoproject.com/ticket/36803#comment:1>

[Django]

#36803: Make AlterField a no-op when ManyToManyField's through.db_table remains the
same between renames.
-------------------------------------+-------------------------------------
Reporter: Clifford Gama | Owner: Clifford
Type: | Gama
Cleanup/optimization | Status: assigned
Component: Migrations | Version: 6.0
Severity: Normal | Resolution:

Keywords: AlterField, no-op, | Triage Stage: Accepted
ManyToManyField |

Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Jacob Walls):

* stage: Unreviewed => Accepted

--
Ticket URL: <https://code.djangoproject.com/ticket/36803#comment:2>

[Django]

#36803: Make AlterField a no-op when ManyToManyField's through.db_table remains the
same between renames.
-------------------------------------+-------------------------------------
Reporter: Clifford Gama | Owner: Clifford
Type: | Gama

Cleanup/optimization | Status: closed
Component: Migrations | Version: 6.0
Severity: Normal | Resolution: wontfix

Keywords: AlterField, no-op, | Triage Stage: Accepted
ManyToManyField |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Changes (by Clifford Gama):

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

Comment:

This is likely not a feasible optimisation with the way the `db_table`
name of an auto-generated `through` model
[https://github.com/django/django/blob/6cc1231285a20b11058143f8cb0a6b4b3999b23a/django/db/models/fields/related.py#L1991-L2002
is backend aware], while the auto detector and `makemigrations` are
backend agnostic. In other words, we have nothing to compare the new
`db_table` with at `makemigrations` time if the `through` model is auto-
created.

Please reopen if I've missed something.

May be related to #33201.
--
Ticket URL: <https://code.djangoproject.com/ticket/36803#comment:3>

[Django]

#36803: Make AlterField a no-op when ManyToManyField's through.db_table remains the
same between renames.
-------------------------------------+-------------------------------------
Reporter: Clifford Gama | Owner: Clifford
Type: | Gama
Cleanup/optimization | Status: closed
Component: Migrations | Version: 6.0
Severity: Normal | Resolution: wontfix
Keywords: AlterField, no-op, | Triage Stage: Accepted
ManyToManyField |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Clifford Gama):

On another note, I just found out that:
{{{#!python
class Book(models.Model):
pass


class Author(models.Model):
books = models.ManyToManyField(Book, through="AuthorBook")


class AuthorBook(models.Model):
book = models.ForeignKey(Book, models.CASCADE)
author = models.ForeignKey(Author, models.CASCADE)
}}}

renaming books, to `articles` without changing anything else results in a
`RemoveField` and `AddField`, though nothing has changed in the schema
--
Ticket URL: <https://code.djangoproject.com/ticket/36803#comment:4>

[Django]

#36803: Make AlterField a no-op when ManyToManyField's through.db_table remains the
same between renames.
-------------------------------------+-------------------------------------
Reporter: Clifford Gama | Owner: Clifford
Type: | Gama

Cleanup/optimization | Status: new

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

Keywords: AlterField, no-op, | Triage Stage: Accepted
ManyToManyField |

Has patch: 1 | Needs documentation: 0

Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Changes (by Clifford Gama):

* has_patch: 0 => 1
* resolution: wontfix =>
* status: closed => new

Comment:

We can still optimise when there is an explicit `db_table`. I opened a
[https://github.com/django/django/pull/20444 PR]
--
Ticket URL: <https://code.djangoproject.com/ticket/36803#comment:5>