Changes between Initial Version and Version 1 of Ticket #23956


Ignore:
Timestamp:
Dec 3, 2014, 6:22:35 AM (10 years ago)
Author:
Kirill Gagarski
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #23956 – Description

    initial v1  
    160160For `D` and `C` it is added via `AddField`. But it seems that `b_ptr` is already added to them even without a field specified in `CreateModel`'s `fields` argument (with the help of `bases` argument, I think).
    161161
     162 == Output of `sqlmigrate` ==
     163{{{
     164BEGIN;
     165CREATE TABLE "migrationstest_a" ("a_id" integer NOT NULL PRIMARY KEY);
     166CREATE TABLE "migrationstest_b" ("b_id" integer NOT NULL PRIMARY KEY);
     167CREATE TABLE "migrationstest_c" ("b_ptr_id" integer NOT NULL UNIQUE, "a_ptr_id" integer NOT NULL PRIMARY KEY);
     168CREATE TABLE "migrationstest_d" ("b_ptr_id" integer NOT NULL UNIQUE, "a_ptr_id" integer NOT NULL PRIMARY KEY);
     169CREATE TABLE "migrationstest_e" ("b_ptr_id" integer NOT NULL UNIQUE, "a_ptr_id" integer NOT NULL PRIMARY KEY);
     170ALTER TABLE "migrationstest_d" ADD COLUMN "b_ptr_id" integer NOT NULL UNIQUE;
     171ALTER TABLE "migrationstest_d" ALTER COLUMN "b_ptr_id" DROP DEFAULT;
     172ALTER TABLE "migrationstest_c" ADD COLUMN "b_ptr_id" integer NOT NULL UNIQUE;
     173ALTER TABLE "migrationstest_c" ALTER COLUMN "b_ptr_id" DROP DEFAULT;
     174ALTER TABLE "migrationstest_c" ADD CONSTRAINT "migrationste_b_ptr_id_6684147e60c05d18_fk_migrationstest_b_b_id" FOREIGN KEY ("b_ptr_id") REFERENCES "migrationstest_b" ("b_id") DEFERRABLE INITIALLY DEFERRED;
     175ALTER TABLE "migrationstest_c" ADD CONSTRAINT "migrationste_a_ptr_id_2670758b3e821055_fk_migrationstest_a_a_id" FOREIGN KEY ("a_ptr_id") REFERENCES "migrationstest_a" ("a_id") DEFERRABLE INITIALLY DEFERRED;
     176ALTER TABLE "migrationstest_d" ADD CONSTRAINT "migrationste_b_ptr_id_2ed6e3025678dfb9_fk_migrationstest_b_b_id" FOREIGN KEY ("b_ptr_id") REFERENCES "migrationstest_b" ("b_id") DEFERRABLE INITIALLY DEFERRED;
     177ALTER TABLE "migrationstest_d" ADD CONSTRAINT "migrationste_a_ptr_id_4d0009d1fad71dec_fk_migrationstest_a_a_id" FOREIGN KEY ("a_ptr_id") REFERENCES "migrationstest_a" ("a_id") DEFERRABLE INITIALLY DEFERRED;
     178ALTER TABLE "migrationstest_e" ADD CONSTRAINT "migrationste_b_ptr_id_29d2159648c59c3e_fk_migrationstest_b_b_id" FOREIGN KEY ("b_ptr_id") REFERENCES "migrationstest_b" ("b_id") DEFERRABLE INITIALLY DEFERRED;
     179ALTER TABLE "migrationstest_e" ADD CONSTRAINT "migrationste_a_ptr_id_405a8eb9707708c9_fk_migrationstest_a_a_id" FOREIGN KEY ("a_ptr_id") REFERENCES "migrationstest_a" ("a_id") DEFERRABLE INITIALLY DEFERRED;
     180ALTER TABLE "migrationstest_d" ADD CONSTRAINT "migrationste_b_ptr_id_2ed6e3025678dfb9_fk_migrationstest_b_b_id" FOREIGN KEY ("b_ptr_id") REFERENCES "migrationstest_b" ("b_id") DEFERRABLE INITIALLY DEFERRED;
     181ALTER TABLE "migrationstest_c" ADD CONSTRAINT "migrationste_b_ptr_id_6684147e60c05d18_fk_migrationstest_b_b_id" FOREIGN KEY ("b_ptr_id") REFERENCES "migrationstest_b" ("b_id") DEFERRABLE INITIALLY DEFERRED;
     182
     183COMMIT;
     184
     185}}}
     186
    162187 = Questions =
    163188Is there a good reasons to do like that? Is there a workaround that can help me to use automatic migration generation without manually editing them (at least initial migration)?
Back to Top