You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[ ] latest
[ ] @next
[x] 0.2.24 (or put your version here)
Steps to reproduce or a small repository showing the problem:
When converting @PrimaryColumn('uuid') to @PrimaryGeneratedColumn('uuid') the migrations/synchronization does not actually update the default value to uuid_generate_v4(), it just drops and recreates all foreign keys. So it will never automatically sync/migrate completely.
Given these entities:
When swapping User's id to be @PrimaryGeneratedColumn('uuid') the resulting up migration looks like:
await queryRunner.query(`ALTER TABLE "document" DROP CONSTRAINT "FK_2d617266bd4cbb6ebcfdb5f67e2"`, undefined);
await queryRunner.query(`ALTER TABLE "document" ADD CONSTRAINT "FK_2d617266bd4cbb6ebcfdb5f67e2" FOREIGN KEY ("ownerId") REFERENCES "user"("id") ON DELETE CASCADE ON UPDATE NO ACTION`, undefined);
As you can see, it does not actually update the default value for the id column in the user table. It just recreates all foreign keys.
I believe there's another bug when going the other way too, the migration tries to remove a sequence that does not exist, the up migration looks like:
await queryRunner.query(`ALTER TABLE "document" DROP CONSTRAINT "FK_2d617266bd4cbb6ebcfdb5f67e2"`, undefined);
await queryRunner.query(`ALTER TABLE "user" ALTER COLUMN "id" DROP DEFAULT`, undefined);
await queryRunner.query(`DROP SEQUENCE "user_id_seq"`, undefined);
await queryRunner.query(`ALTER TABLE "document" ADD CONSTRAINT "FK_2d617266bd4cbb6ebcfdb5f67e2" FOREIGN KEY ("ownerId") REFERENCES "user"("id") ON DELETE CASCADE ON UPDATE NO ACTION`, undefined);
When using uuid there are no sequences. But when the sequence is removed from the migration, it does update the default value for the id column and future sync/migrations will be empty.
With this small case it's easy to see the issue, in my real-world case I'm migrating a code base to TypeORM and wanted to set a generated primary key uuid on an existing table.
Also, thanks for a great library!
The text was updated successfully, but these errors were encountered:
I met the same problem - when switching from PrimaryKey('uuid') to PrimaryGeneratedColumn('uuid'), typeorm generates a migration which re-creates all foreign key constraints related with this table.
…d/remove the DEFAULT value (#8274)
* fix(8273) Adding @generated('uuid') will now generate a migration to add the DEFAULT value
* implemented fix for "increment" generation type;
implemented fix for generation removal;
improved tests;
* added test for #5898
Co-authored-by: AlexMesser
Issue type:
[ ] question
[x] bug report
[ ] feature request
[ ] documentation issue
Database system/driver:
[x]
postgres
TypeORM version:
[ ]
latest
[ ]
@next
[x]
0.2.24
(or put your version here)Steps to reproduce or a small repository showing the problem:
When converting
@PrimaryColumn('uuid')
to@PrimaryGeneratedColumn('uuid')
the migrations/synchronization does not actually update the default value touuid_generate_v4()
, it just drops and recreates all foreign keys. So it will never automatically sync/migrate completely.Given these entities:
When swapping User's id to be
@PrimaryGeneratedColumn('uuid')
the resultingup
migration looks like:As you can see, it does not actually update the default value for the
id
column in theuser
table. It just recreates all foreign keys.I believe there's another bug when going the other way too, the migration tries to remove a sequence that does not exist, the
up
migration looks like:When using uuid there are no sequences. But when the sequence is removed from the migration, it does update the default value for the
id
column and future sync/migrations will be empty.With this small case it's easy to see the issue, in my real-world case I'm migrating a code base to TypeORM and wanted to set a generated primary key uuid on an existing table.
Also, thanks for a great library!
The text was updated successfully, but these errors were encountered: