1 | There should be two files attached, models-0001.py and models-0002.py. Copy
|
---|
2 | them into an application directory x, and symlink one or the other to generate
|
---|
3 | the initial and changed migrations. The comments in those classes may reflect
|
---|
4 | an early, flawed understanding of the bugs, so don't place too much faith in
|
---|
5 | what they claim to test. Not going to change anything there now...
|
---|
6 |
|
---|
7 | with models-0001, no migrations:
|
---|
8 |
|
---|
9 | Creating tables...
|
---|
10 | Creating table x_ring
|
---|
11 | Creating table x_one
|
---|
12 | Creating table x_twosies
|
---|
13 | Creating table x_three_ring
|
---|
14 | Creating table x_three
|
---|
15 | Creating table x_four_ring
|
---|
16 | Creating table x_four
|
---|
17 |
|
---|
18 | Okay, that's all correct! Let's clear everything out and verify with models-0002:
|
---|
19 |
|
---|
20 | Creating tables...
|
---|
21 | Creating table x_ring
|
---|
22 | Creating table x_one
|
---|
23 | Creating table x_twosies
|
---|
24 | Creating table x_three_ring
|
---|
25 | Creating table x_three
|
---|
26 | Creating table x_four_ringsie
|
---|
27 | Creating table x_four
|
---|
28 |
|
---|
29 | x_three and x_four are never a problem, so summarizing the above and what happens
|
---|
30 | when the tables are built by migrations (models-0001 first, then models-0002 for
|
---|
31 | the second migration):
|
---|
32 |
|
---|
33 | Source says non-migration migration 0001 migration 0002 migration 0002
|
---|
34 | creates creates (all "no") sensible yeses
|
---|
35 |
|
---|
36 | x_one x_one x_one x_one x_onsies ???
|
---|
37 |
|
---|
38 | x_twosies x_twosies x_twosies x_twosies x_twosies
|
---|
39 |
|
---|
40 | x_three_ring x_three_ring x_three_ring x_three_ring x_three_ringsies
|
---|
41 |
|
---|
42 | x_four_ring (#1) x_four_ring x_four_ringsie !
|
---|
43 |
|
---|
44 | x_four_ringsies (#2) x_four_ringsies x_four_ringsies x_four_ringsies
|
---|
45 |
|
---|
46 | Migration 0002 is so full of fail that I need to present it differently. There are
|
---|
47 | choices to be made, y'see. So if I interpret it literally, the true answers are
|
---|
48 | all "no" and it looks like this:
|
---|
49 |
|
---|
50 | Did you rename the x.Two model to Onesie? [y/N] n
|
---|
51 | Did you rename the x.One model to Onesie? [y/N] n
|
---|
52 | Did you rename the x.Two model to Twosies? [y/N] n
|
---|
53 | Did you rename the x.One model to Twosies? [y/N] n
|
---|
54 | Did you rename four.ringsie to four.ring (a ManyToManyField)? [y/N] n
|
---|
55 | Did you rename three.ring to three.ringsies (a ManyToManyField)? [y/N] n
|
---|
56 | Migrations for 'x':
|
---|
57 | 0002_auto_20140726_0149.py:
|
---|
58 | - Create model Onesie
|
---|
59 | - Create model Twosies
|
---|
60 | - Delete model One
|
---|
61 | - Delete model Two
|
---|
62 | - Add field ring to four
|
---|
63 | - Add field ringsies to three
|
---|
64 | - Remove field ringsie from four
|
---|
65 | - Remove field ring from three
|
---|
66 |
|
---|
67 | Oddly, applying this does NOT make x_onesies - see above (all "no"). But trying
|
---|
68 | to rewind to 0001 fails: table "x_three_ring" already exists, so clearly things
|
---|
69 | are screwed up.
|
---|
70 |
|
---|
71 | Clearing it all out, sqlmigrate 0002 gives this marvellous nonsense:
|
---|
72 |
|
---|
73 | CREATE TABLE "x_one" ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT, "name" varchar(40) NOT NULL);
|
---|
74 | CREATE TABLE "x_twosies" ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT, "name" varchar(40) NOT NULL);
|
---|
75 | DROP TABLE "x_one";
|
---|
76 | DROP TABLE "x_twosies";
|
---|
77 | CREATE TABLE "x_four_ring" ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT, "four_id" integer NOT NULL REFERENCES "x_four" ("id"), "ring_id" integer NOT NULL REFERENCES "x_ring" ("id"), UNIQUE ("four_id", "ring_id"));
|
---|
78 | CREATE TABLE "x_three_ringsies" ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT, "three_id" integer NOT NULL REFERENCES "x_three" ("id"), "ring_id" integer NOT NULL REFERENCES "x_ring" ("id"), UNIQUE ("three_id", "ring_id"));
|
---|
79 | DROP TABLE "x_four_ringsie";
|
---|
80 | DROP TABLE "x_three_ring";
|
---|
81 | CREATE INDEX x_four_ring_d1a8cfcf ON "x_four_ring" ("four_id");
|
---|
82 | CREATE INDEX x_four_ring_66194dd2 ON "x_four_ring" ("ring_id");
|
---|
83 | CREATE INDEX x_three_ringsies_375bdf5f ON "x_three_ringsies" ("three_id");
|
---|
84 | CREATE INDEX x_three_ringsies_66194dd2 ON "x_three_ringsies" ("ring_id");
|
---|
85 |
|
---|
86 | And at this point I've added what my notes from an earlier test showed when answering
|
---|
87 | yes or no as was sensible (viz., correct, except for an incorrect change of table name).
|
---|
88 | All these rubbish errors have me too out of sorts to regenerate it all and start over to
|
---|
89 | verify that.
|
---|
90 |
|
---|
91 | It seems clear that there's a problem in the model "parsing", and IMO the earlier patch
|
---|
92 | that closed #22975 is a bandaid over the problem (and maybe doesn't work in all cases,
|
---|
93 | if that x_onesies I recorded was really there). In the M2M intermediary table it's
|
---|
94 | clear that it simply ignores the db_table that Django itself resolves altogether; I
|
---|
95 | suspect that same sore of blindness is the actual cause of the other bug as well. I
|
---|
96 | have not gone spelunking in the new migrations code nearly enough to demonstrate that
|
---|
97 | myself. ;-/
|
---|
98 |
|
---|