I have a Postgres table like this:
Table "public.topic"
Column | Type | Modifiers | Storage | Stats target | Description
----------------+--------------------------+----------------------------------------------------+----------+--------------+-------------
id | integer | not null default nextval('topic_id_seq'::regclass) | plain | |
parent_topicid | integer | | plain | |
topic | character varying | | extended | |
public | boolean | default true | plain | |
creator | character varying(12) | collate et_EE default NULL::character varying | extended | |
created | timestamp with time zone | not null default now() | plain | |
updater | character varying(12) | collate et_EE default NULL::character varying | extended | |
updated | timestamp with time zone | default now() | plain | |
Indexes:
"topic_pkey" PRIMARY KEY, btree (id)
"topic_parent_topicid_idx" btree (parent_topicid)
Foreign-key constraints:
"topics_have_parent" FOREIGN KEY (parent_topicid) REFERENCES topic(id) ON DELETE SET NULL
Referenced by:
TABLE "book.book_topic" CONSTRAINT "book_topic_belongs_to_topic" FOREIGN KEY (topicid) REFERENCES topic(id) ON DELETE CASCADE
TABLE "card.card_topic" CONSTRAINT "card_topic_belongs_to_topic" FOREIGN KEY (topicid) REFERENCES topic(id) ON DELETE CASCADE
TABLE "print.print_topic" CONSTRAINT "print_topic_belongs_to_topic" FOREIGN KEY (topicid) REFERENCES topic(id) ON DELETE CASCADE
TABLE "antique.antique_topic" CONSTRAINT "topic_antique_belongs_to_topic" FOREIGN KEY (topicid) REFERENCES topic(id) ON DELETE CASCADE
TABLE "lp.lp_topic" CONSTRAINT "topic_lp_belongs_to_topic" FOREIGN KEY (topicid) REFERENCES topic(id) ON DELETE CASCADE
TABLE "stationary.stationary_topic" CONSTRAINT "topic_stationary_belongs_to_topic" FOREIGN KEY (topicid) REFERENCES topic(id) ON DELETE CASCADE
TABLE "topic" CONSTRAINT "topics_have_parent" FOREIGN KEY (parent_topicid) REFERENCES topic(id) ON DELETE SET NULL
Triggers:
topic_delete AFTER DELETE ON topic FOR EACH ROW EXECUTE PROCEDURE add_into_queue_task()
topic_update AFTER UPDATE ON topic FOR EACH ROW EXECUTE PROCEDURE add_into_queue_task()
update_topic_updated BEFORE UPDATE ON topic FOR EACH ROW EXECUTE PROCEDURE update_updated_column()
parent_topicid
-field is recursive, pointing to the primary key.
With npx prisma db pull
Prisma created the corresponding model:
model topic {
id Int @id @default(autoincrement())
parent_topicid Int?
topic String? @db.VarChar
public Boolean? @default(true)
creator String? @db.VarChar(12)
created DateTime @default(now()) @db.Timestamptz(6)
updater String? @db.VarChar(12)
updated DateTime? @default(now()) @db.Timestamptz(6)
antique_topic antique_topic[]
book_topic book_topic[]
card_topic card_topic[]
lp_topic lp_topic[]
print_topic print_topic[]
topic topic? @relation("topicTotopic", fields: [parent_topicid], references: [id], onUpdate: NoAction, map: "topics_have_parent")
other_topic topic[] @relation("topicTotopic")
stationary_topic stationary_topic[]
@@index([parent_topicid])
@@schema("public")
}
Now I tried to make initial baseline for migration:
$ npx prisma migrate diff --from-empty --to-schema-datamodel prisma/schema.prisma --script > prisma/migrations/0_init/migration.sql
Error: P1012
error: Field "topic" is already defined on model "topic".
--> schema.prisma:1340
|
1339 | print_topic print_topic[]
1340 | topic topic? @relation("topicTotopic", fields: [parent_topicid], references: [id], onUpdate: NoAction, map: "topics_have_parent")
|
As you may see, Prisma is not happy with the field it automatically created from my table. From my perspective, the table is set up correctly. What should I do to get a baseline created?
The issue is that Prisma is encountering a conflict because the name "topic" is being used for both a field and a relation in your model.
Try changing
topic topic? @relation("topicTotopic", fields: [parent_topicid], references: [id], onUpdate: NoAction, map: "topics_have_parent")
to:
parentTopic topic? @relation("topicTotopic", fields: [parent_topicid], references: [id], onUpdate: NoAction, map: "topics_have_parent")
also the autogenerated other_topics sounds odd, perhaps sub_topics is a better name