feat(se): allow model/table renaming in postgres and sqlserver

[eruditmorina]

if a developer wants to rename a model/table, Prisma Migrate currently diffs the two models and generates a migration to drop the previous table and create a new table.

This PR's purpose is to introduce a mechanism that knows if a table is renamed and for Prisma to generate a migration that renames the table properly. To do so, the renamed table must be identifiable with high certainty.

For databases that support naming primary key constraints (Postgres, SQLServer), we can check if the table is being renamed by looking at the key. If the key is the same, the table is the same.

So, this feature would apply to those supported databases, for now, and for cases when primary key is not given a specific name, the default behavior of dropping and recreating the table would apply.

Example:

// Before
model User {
  id        Int      @id
  email     String
}

//After
model Person {
  id        Int      @id
  email     String
}

Renaming table User to Person, will simply, as always, drop table User and create table Person. But:

// Before
model User {
  id        Int      @id(map: "custom_id")
  email     String
}

//After
model Person {
  id        Int      @id(map: "custom_id")
  email     String
}

By setting a name to the primary key of the table, renaming table User to Person, will generate the following query:

ALTER TABLE "User" RENAME TO "Person";

Related issues:

• Allow Model/table renaming without data loss prisma#12387
• Best way to rename a prisma model without data loss? prisma#11170
• Prisma Migrate: handle field renames interactively  prisma#7790 (but only for tables)

[janpio]

For databases that support naming primary key constraints (Postgres, SQLServer), we can check if the table is being renamed by looking at the key. If the key is the same, the table is the same.

Is that guaranteed?

Some thoughts after thinking about this for not too long, so potentially irrelevant/wrong:

1. Couldn't there be cases where the primary key name of a different model/table is also modified in a way that it is then falsely identified as the new table?
2. The difference between renaming and dropping is that with the latter the data is removed as well. Couldn't it be that the user generally intends the data to be dropped when renaming a model?

[codspeed-hq]

CodSpeed Performance Report

Merging #4914 will not alter performance

_{Comparing eruditmorina:eruditmorina/schema-engine/allow-table-renaming (c27b7da) with main (9ee8c02)}

Summary

✅ 11 untouched benchmarks

[eruditmorina]

@janpio thanks for commenting on this.

1. If there is a case where the primary key of a different table is modified, considering that table is not being also renamed, there would be no problem. But if both primary key and table name are modified, then it will default to dropping the table and recreating it.
2. if the intent of the developer is to drop and recreate table, then they may leave primary key with default name, or modify it together with the table name, in which case the drop and recreate will apply.

[janpio]

Heads up:

We had an internal conversation that we probably would want to offer this to our users as a choice, via an interactive prompt, instead of using some heuristics to decide for them. But we also realize that implementing this prompt is probably quite a big lift, as it would possibly completely need to change how Prisma CLI and Schema Engine communicate during migrate dev.

Do you think that makes sense?

[eruditmorina]

@janpio

I understand that predicting renames with certainty is not a trivial problem. I achieved that for Postgres and SQLServer only because those databases support names for primary key constraints, which helped in safely finding tables that are renamed.

But in order to enable the feature for other databases, and furthermore enabling something like column renames, there are limitations that prevent us from knowing exactly the user's intent and making the decision for them. So, even though it would be a big change on how the client and schema engine communicate, it makes a ton of sense to reach for an interactivity.

Thanks