prisma1-upgrade
prisma1-upgrade copied to clipboard
Required queries keep persisting after executing them
I am up to the part of the upgrade process where you execute the following command:
npx prisma-upgrade prisma1/prisma.yml prisma/schema.prisma
It prints out the following statement:
Migrate IDs from varchar(25) to varchar(30) https://pris.ly/d/schema-incompatibilities#mismatching-cuid-length
ALTER TABLE "start-bee-dev$dev"."Answer" ALTER COLUMN "id" SET DATA TYPE character varying(30);
ALTER TABLE "start-bee-dev$dev"."Answer" ALTER COLUMN "createdForQuestion" SET DATA TYPE character varying(30);
ALTER TABLE "start-bee-dev$dev"."Answer" ALTER COLUMN "poster" SET DATA TYPE character varying(30);
ALTER TABLE "start-bee-dev$dev"."BlogArticle" ALTER COLUMN "id" SET DATA TYPE character varying(30);
ALTER TABLE "start-bee-dev$dev"."Conversation" ALTER COLUMN "id" SET DATA TYPE character varying(30);
ALTER TABLE "start-bee-dev$dev"."Conversation" ALTER COLUMN "blockedUser" SET DATA TYPE character varying(30);
ALTER TABLE "start-bee-dev$dev"."HoursPerWeek" ALTER COLUMN "id" SET DATA TYPE character varying(30);
ALTER TABLE "start-bee-dev$dev"."IdeaStage" ALTER COLUMN "id" SET DATA TYPE character varying(30);
ALTER TABLE "start-bee-dev$dev"."Industry" ALTER COLUMN "id" SET DATA TYPE character varying(30);
ALTER TABLE "start-bee-dev$dev"."KnowledgePoints" ALTER COLUMN "id" SET DATA TYPE character varying(30);
ALTER TABLE "start-bee-dev$dev"."KnowledgePoints" ALTER COLUMN "awardedFromAnswer" SET DATA TYPE character varying(30);
ALTER TABLE "start-bee-dev$dev"."KnowledgePoints" ALTER COLUMN "awardedFromQuestion" SET DATA TYPE character varying(30);
ALTER TABLE "start-bee-dev$dev"."KnowledgePoints" ALTER COLUMN "createdBy" SET DATA TYPE character varying(30);
ALTER TABLE "start-bee-dev$dev"."Message" ALTER COLUMN "id" SET DATA TYPE character varying(30); ALTER TABLE "start-bee-dev$dev"."Message" ALTER COLUMN "createdBy" SET DATA TYPE character varying(30);
ALTER TABLE "start-bee-dev$dev"."Message" ALTER COLUMN "createdFor" SET DATA TYPE character varying(30);
ALTER TABLE "start-bee-dev$dev"."Question" ALTER COLUMN "id" SET DATA TYPE character varying(30);
ALTER TABLE "start-bee-dev$dev"."Question" ALTER COLUMN "poster" SET DATA TYPE character varying(30);
ALTER TABLE "start-bee-dev$dev"."Question" ALTER COLUMN "type" SET DATA TYPE character varying(30);
ALTER TABLE "start-bee-dev$dev"."QuestionType" ALTER COLUMN "id" SET DATA TYPE character varying(30);
ALTER TABLE "start-bee-dev$dev"."ReportedFrom" ALTER COLUMN "id" SET DATA TYPE character varying(30);
ALTER TABLE "start-bee-dev$dev"."Skill" ALTER COLUMN "id" SET DATA TYPE character varying(30);
ALTER TABLE "start-bee-dev$dev"."StartupStage" ALTER COLUMN "id" SET DATA TYPE character varying(30);
ALTER TABLE "start-bee-dev$dev"."Tag" ALTER COLUMN "id" SET DATA TYPE character varying(30);
ALTER TABLE "start-bee-dev$dev"."Tag" ALTER COLUMN "createdBy" SET DATA TYPE character varying(30);
ALTER TABLE "start-bee-dev$dev"."User" ALTER COLUMN "id" SET DATA TYPE character varying(30);
ALTER TABLE "start-bee-dev$dev"."User" ALTER COLUMN "hoursPerWeekAvailable" SET DATA TYPE character varying(30);
ALTER TABLE "start-bee-dev$dev"."User" ALTER COLUMN "ideaIndustry" SET DATA TYPE character varying(30);
ALTER TABLE "start-bee-dev$dev"."User" ALTER COLUMN "ideaStage" SET DATA TYPE character varying(30);
ALTER TABLE "start-bee-dev$dev"."User" ALTER COLUMN "startupIndustry" SET DATA TYPE character varying(30);
ALTER TABLE "start-bee-dev$dev"."User" ALTER COLUMN "startupStage" SET DATA TYPE character varying(30);
I have run this SQL query multiple times using different Postgresql clients and even different machines but no matter what it always comes back with the above query. Looking at the first query:
ALTER TABLE "start-bee-dev$dev"."Answer" ALTER COLUMN "id" SET DATA TYPE character varying(30);
I have checked this in the DB schema and it looks like the value has indeed been updated to 30 so I don't understand why it's not picking up my change? I thought maybe it was some kind of caching issue but after switching machines and seeing the same issue I don't believe it's anything to do with my local cache or anything
Possibly related to https://github.com/prisma/upgrade/issues/89#issuecomment-712808678
This has been confirmed as a bug by the Prisma team. As all values have been updated it is safe to move onto the next step in the migration
I'm reopening this issue so that it's on our radar and can get fixed in the CLI.
Any progress on this issue? I can imagine there will be quite a few groups looking to migrate given the upcoming sunset date. We had hoped to use this as a checklist / burndown of sorts, especially as we're performing a side-by-side upgrade. Our other teams are continuing to evolve the Prisma 1 schema, so this would be helpful for us as it would make it also easier to identify new statements that need to be executed.