Changing name of M2MField while db_table keeps table name unchanged leads to spurious migration that changes table name

[maney@…]

This is the terse version, I'm going to revisit this later as I think this and #22975 share similar root cause: using the apparent/default name and overlooking the db_table that actually sets the table's name.

In Model "Some", have a field like

x = ManyToManyField("Other") # table name app_some_x

Change that to

x_set = ManyToManyField("Other", db_table="app_some_x")

which doesn't actually change anything in the schema, but the migration sees it as a rename of the intermediate table, generates a migration, and changes the name. At this point you can observe in the shell that eg., Some.x_set.field.m2m_db_table() -> app_some_x, but the table in the database has been migrated to app_some_x_set.

(caveat: the above hasn't been tested per se, I'm summarizing to get this on record before I have to go. Marked as 1.7, but while chatting with Andrew I did check it against master - no change.)

[maney@…]

models-0001

[maney@…]

models-0002

[maney@…]

description of test results, speculation about root cause

[Baptiste Mispelon]

Hi,

I cna reproduce the issue with a very simple scenario and it seems quite serious.

Using these models:

class Foo(models.Model):
    pass


class Bar(models.Model):
    foos = models.ManyToManyField("Foo", db_table='custom_table')

Running manage.py makemigrations and manage.py migrate creates a table called <app_name>__bar_foos instead of custom_table.

This works fine in 1.6 so it's definitely a release blocker.

Thanks.

[abraham.martin]

fix

[Abraham Martin <abraham@…>]

In 999758fc7a2d6fcb01eb40de937d4420f884788d:

Fixed #23101 db_table wasn't copied in deconstruct

[Andrew Godwin <andrew@…>]

In 37f8a83ad050a1040712876002edcbfc0b057603:

Merge pull request #2977 from abrahammartin/stable/1.7.x

Fixed #23101 db_table wasn't copied in deconstruct

[Andrew Godwin <andrew@…>]

In e1347e9253821a31f9896de9eb993e2376e7398f:

Fixed #23101 db_table wasn't copied in deconstruct

Forward port of 999758fc7a2d6fcb01eb40de937d4420f884788d from
stable/1.7.x

[maney@…]

The changes in RC2 fix the initial creation, but do little or nothing for the second migration - that still such a mess that I'm not even sure how many ways it fails, though I believe the error reported is the same as ever:

OperationalError: table "x_three_ring" already exists

This is the migration from model-0001 (the initial state) to model-0002

[Andrew Godwin]

I cannot replicate - running the models.py files as supplied works perfectly. Can you verify that this still fails for you on the latest master?

[Mattias Linnap <mattias@…>]

On both 1.7 RC2 and master, makemigrations and migrate run without errors.
For models One and Two it asks you if you renamed the models. But for models Three and Four, the old fields are removed and new fields are added instead of being detected as renames:

Did you rename the foo.One model to Onesie? [y/N] y
Did you rename the foo.Two model to Twosies? [y/N] y
Migrations for 'foo':
  0002_auto_20140728_1821.py:
    - Rename model One to Onesie
    - Rename model Two to Twosies
    - Add field ring to four
    - Add field ringsies to three
    - Remove field ringsie from four
    - Remove field ring from three

This may or may not be correct, depending on how clever the rename detector is supposed to be?

[Andrew Godwin <andrew@…>]

In a338e0773592ce4030407428c77815a713b6c9c7:

Fixed #23101: Prefer doing deletes before creates in autodetector.

Makes declined or missed renames still work (but drop data).

[Andrew Godwin <andrew@…>]

In 0a4fbf4e13b194383f9eecc0af337a50fb6dfe98:

[1.7.x] Fixed #23101: Prefer doing deletes before creates in autodetector.

Makes declined or missed renames still work (but drop data).

[Andrew Godwin]

The rename detector prefers false negatives rather than false positives, so this is expected behaviour.

However, declining or missing the rename was making django emit a CREATE then a DELETE for the fields in that order, rather than (correctly) DELETE then CREATE. I've fixed this, so at least it'll run without errors.