Error parsing attribute "@relation": The type of the field `<field>` in the model `<model>` is not matching the type of the referenced field `id` in model `<model2>`.

Bug description

prisma introspect with native types produces invalid schema.

How to reproduce

1. Deploy the following SQL

CREATE TABLE public.grading_periods (
    id bigint NOT NULL,
    grading_period_group_id integer NOT NULL
);

ALTER TABLE ONLY public.grading_periods
    ADD CONSTRAINT grading_periods_pkey PRIMARY KEY (id);

CREATE TABLE public.grading_period_groups (
    id bigint NOT NULL
);

ALTER TABLE ONLY public.grading_period_groups
    ADD CONSTRAINT grading_period_groups_pkey PRIMARY KEY (id);

ALTER TABLE ONLY public.grading_periods
    ADD CONSTRAINT fk_rails_9cc118401a FOREIGN KEY (grading_period_group_id) REFERENCES public.grading_period_groups(id);

1. prisma introspect (with nativeTypes flag) produces

model grading_period_groups {
  id              BigInt            @id @db.BigInt
  grading_periods grading_periods[]
}

model grading_periods {
  id                      BigInt                @id @db.BigInt
  grading_period_group_id Int                   @db.Integer
  grading_period_groups   grading_period_groups @relation(fields: [grading_period_group_id], references: [id])
}

1. prisma validate returns

(base) divyendusingh [prisma-explicit-panic]$ yarn prisma validate
yarn run v1.22.4
$ /Users/divyendusingh/Documents/prisma/triage/prisma-explicit-panic/node_modules/.bin/prisma validate
Prisma schema loaded from schema.prisma
Error: Schema parsing
error: Error parsing attribute "@relation": The type of the field `grading_period_group_id` in the model `grading_periods` is not matching the type of the referenced field `id` in model `grading_period_groups`.
  -->  schema.prisma:19
   | 
18 |   grading_period_group_id Int                   @db.Integer
19 |   grading_period_groups   grading_period_groups @relation(fields: [grading_period_group_id], references: [id])
20 | }
   | 

Prisma information

(base) divyendusingh [prisma-explicit-panic]$ yarn prisma --version                                                                                                                  130 ↵
yarn run v1.22.4
$ /Users/divyendusingh/Documents/prisma/triage/prisma-explicit-panic/node_modules/.bin/prisma --version
@prisma/cli          : 2.16.0-dev.17
@prisma/client       : 2.16.0-dev.17
Current platform     : darwin
Query Engine         : query-engine d621d9b01ebb4c8fcd3adeaf3421e0149c676c58 (at node_modules/@prisma/engines/query-engine-darwin)
Migration Engine     : migration-engine-cli d621d9b01ebb4c8fcd3adeaf3421e0149c676c58 (at node_modules/@prisma/engines/migration-engine-darwin)
Introspection Engine : introspection-core d621d9b01ebb4c8fcd3adeaf3421e0149c676c58 (at node_modules/@prisma/engines/introspection-engine-darwin)
Format Binary        : prisma-fmt d621d9b01ebb4c8fcd3adeaf3421e0149c676c58 (at node_modules/@prisma/engines/prisma-fmt-darwin)
Studio               : 0.343.0
Preview Features     : nativeTypes
✨  Done in 1.75s.

[janpio]

An alternative workaround here might be to lie to Prisma. Instead of trying to generate a client with two non matching columns in the relation, change the bigger one to actually have the type of the smaller one. This will not reflect reality, but e.g. for Int and BigInt this should be fine assuming your data confirms to that and does not include BigInts. Then the error should go away, you should be able to use the full API of Prisma on your models.

(Although a discussion happens here, this is in the end “just” a feature request to enable this behavior. If we want to keep guidance for users around how to handle this specific case, we should put it into our documentation as a workaround for a limitation (“Prisma does not support foreign keys with different data types - this is what you can do to work with that database in Prisma anyway”).

[carchrae]

answering my own question

is it possible to get prisma to skip the validation check on a particular line? along the lines of /* eslint-disable no-eval */

i just commented out the lines in question. obviously, this means i cannot use prisma to access any of these values, however, it means that i can fix them as i need to. (i am slowly porting a legacy code base over to prisma)