prisma1-upgrade
prisma1-upgrade copied to clipboard
Prisma-upgrade produces duplicates for relations: Field 'X' is already defined on modal 'Y'
We have been using Prisma 1.34 for a while now, at multiple servers with the same schema. We are currently attempting to upgrade the prisma-layer to prisma2. We really enjoy the tooling around prisma now, it looks very good.
However, we ran into an issue with the generated schema.prisma
-file:
Field "archiveId" is already defined on model "Action".
Of course, I do not expect that an automated tool like this will be perfect, I understand there are lots of edge-cases. I was hoping however that I could be guided into the right direction on how these should be updated.
- Relevant Prisma1-schema:
type Action {
id: ID! @id
archive: CompressedArchive
@relation(link: INLINE, name: "ActionCompressedArchive")
}
type CompressedArchive {
id: ID! @id
deletion: Action! @relation(name: "ActionDeletionCompressedArchive")
creation: Action! @relation(name: "ActionCreationCompressedArchive")
}
- run:
yarn prisma init
yarn prisma introspect
This resulted in this schema.prisma
:
model Action {
id String @id
archive String?
CompressedArchive_Action_archiveToCompressedArchive CompressedArchive? @relation("Action_archiveToCompressedArchive", fields: [archive], references: [id])
CompressedArchive_ActionToCompressedArchive_creation CompressedArchive[] @relation("ActionToCompressedArchive_creation")
CompressedArchive_ActionToCompressedArchive_deletion CompressedArchive[] @relation("ActionToCompressedArchive_deletion")
}
model CompressedArchive {
id String @id
creation String?
deletion String?
Action_ActionToCompressedArchive_creation Action? @relation("ActionToCompressedArchive_creation", fields: [creation], references: [id])
Action_ActionToCompressedArchive_deletion Action? @relation("ActionToCompressedArchive_deletion", fields: [deletion], references: [id])
Action_Action_archiveToCompressedArchive Action[] @relation("Action_archiveToCompressedArchive")
CompressedArchiveFile CompressedArchiveFile[] @relation("CompressedArchiveToArchiveFile")
}
- run
prisma-upgrade
- . Apply the non-breaking suggested changes.
It returned these postgres-commands:
ALTER TABLE "default$default"."Action" ALTER COLUMN "id" SET DATA TYPE character varying(30);
ALTER TABLE "default$default"."Action" ALTER COLUMN "archive" SET DATA TYPE character varying(30);
ALTER TABLE "default$default"."Action" ALTER COLUMN "connectorConfig" SET DATA TYPE character varying(30);
ALTER TABLE "default$default"."Action" ALTER COLUMN "file" SET DATA TYPE character varying(30);
ALTER TABLE "default$default"."CompressedArchive" ALTER COLUMN "id" SET DATA TYPE character varying(30);
ALTER TABLE "default$default"."CompressedArchive" ALTER COLUMN "creation" SET DATA TYPE character varying(30);
ALTER TABLE "default$default"."CompressedArchive" ALTER COLUMN "deletion" SET DATA TYPE character varying(30);
ALTER TABLE "default$default"."CompressedArchive" ALTER COLUMN "owner" SET DATA TYPE character varying(30);
I performed these operations, and then ran yarn prisma introspect again
- prisma introspect
I repeated the above process once more, but it only returned part of the same ALTER-commands that had already been aplied.
The, I continued to prisma-upgrade
and applied the last step. This is where my schema.prisma
retuned an invalid schema
the relevant part of schema.prisma
:
model Action {
id String @id @default(cuid())
archiveId String? @map("archive")
archiveId CompressedArchive? @map("archive") @relation("Action_archiveToCompressedArchive", fields: [archive], references: [id])
archiveId CompressedArchive[] @map("archive") @relation("ActionToCompressedArchive_creation")
archive CompressedArchive[] @relation("ActionToCompressedArchive_deletion")
}
model CompressedArchive {
id String @id @default(cuid())
creationId String? @map("creation")
deletionId String? @map("deletion")
creationId Action? @map("creation") @relation("ActionToCompressedArchive_creation", fields: [creation], references: [id])
creationId Action? @map("creation") @relation("ActionToCompressedArchive_deletion", fields: [deletion], references: [id])
creation Action[] @relation("Action_archiveToCompressedArchive")
We also see similar issues for other types. In total, there is 26 errors, all of them are the same.
At this point, I am unable to run yarn prisma generate
. Am I doing something wrong here?
Hey @runar-indico, sorry about the inconvenience here. You're correct that there are a bunch of edge cases to deal with, so the generated schema often requires some manual tweaking.
The char(25) => char(30) being repeated is expected, unfortunately. Since we don't connect to your database with the upgrade tool and don't store these differences in the Prisma Schema, we can't know these specific details.
At first glance, I'm really not sure why it's showing up 3 different times.
Your data model looks quite similar to this example except that it's an optional 1-1.
Is that the case? If so, I can quickly try reproducing it.
Thank you for responding, greatly appreaciated. Yes, that part looks very similar.
It might also be relavant that I have two fields that have relations to the same type, my CompressedArchive
has a creation
and deletion
. Both should be required relations. It does not look like prisma introspect
have picked up on it being required. I also thought it was a n-1-relation, e.g. there could be multiple relations.
The Action-type is correctly inferring that there is an optional relation to Compressed Archive.
See my Prisma1-schema above, or here, I copied it to make it a bit easier to find:
type Action {
id: ID! @id
archive: CompressedArchive
@relation(link: INLINE, name: "ActionCompressedArchive")
}
type CompressedArchive {
id: ID! @id
deletion: Action! @relation(name: "ActionDeletionCompressedArchive")
creation: Action! @relation(name: "ActionCreationCompressedArchive")
}
@matthewmueller Did you have a chance to look at this? Any advice for how we might move on?
Facing a similar issue right now, but not sure how to proceed without breaking anything in the process.
same issue. Waiting for solution.