Support for schema definitions that are not overwritten by a prisma db pull

[blevine]

Based on discussion started here.

This is an idea for an enhancement to prisma db pull. I realize that this is not Prisma's main use-case, but:

I am accessing a database via Prisma for which I don't own the DB schema and so I can't modify it. I would like to be able to "compensate" for certain deficiencies in the DB schema at the Prisma schema level. Here is an example,

The DB defines a user_group_membership relational table that generates a Prisma schema like so:

model user_group_membership {
  group_id    String      @db.VarChar(36)
  user_id     String      @db.VarChar(36)
  user_entity user_entity @relation(fields: [user_id], references: [id], onDelete: NoAction, onUpdate: NoAction, map: "fk_user_group_user")

  @@id([group_id, user_id], map: "constraint_user_group")
  @@index([user_id], map: "idx_user_group_mapping")
}

The DB schema did not define group_id as a foreign key and so the Prisma schema does not include the relationship to the group table. However, I can modify the Prisma schema to include that relationship recognizing that queries will be non-optimal since no index exists on group_id. That's OK for my use case. By doing that, I can then create Prisma queries with include: group.

Even though I can't modify the DB schema for existing tables, I can add my own tables. For reasons I don't want to go into here, I'm using Knex migrations to manage this. So my workflow has been:

create Knex migration -> execute migration -> prisma db pull -> prisma generate

The problem is that this will overwrite the manual changes that I made to the Prisma schema.

To solve this, I'm imagining some sort of new annotation (let's say @keep or @protected) that identifies certain declarations in the schema.prisma that should be carried forward and not overwritten during prisma db pull.

If there's some other way for me to go about this without an enhancement to Prisma, please let me know. Otherwise, I wonder if this could be considered as a viable future enhancement. Where "future" == "not too far in the future" ;-)

[floelhoeffel]

Thanks for the detailed issue @blevine - we have categorized it but its unfortunately unlikely that we will get to this short/mid-term. We are going to look into schemas in 2022 and will consider your feedback though!