-
Notifications
You must be signed in to change notification settings - Fork 244
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(schema-engine): use pk for implicit join tables on postgres #5057
Conversation
CodSpeed Performance ReportMerging #5057 will not alter performanceComparing Summary
|
WASM Query Engine file Size
|
b7ad81e
to
1081887
Compare
schema-engine/connectors/sql-schema-connector/src/sql_schema_calculator.rs
Outdated
Show resolved
Hide resolved
// automatically derived total order relation between `SqlMigrationStep`s). If we need more | ||
// complex ordering logic in the future, we should consider defining a partial order on | ||
// `SqlMigrationStep` where only the pairs for which order actually matters are ordered, | ||
// building a graph from the steps and topologically sorting it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Topological graph + explicit partial order would probably be the best course of action in the long term.
Currently, we need to manually be careful when defining the operations that impact the schema.prisma
<-> SQL
translation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice one!
Co-authored-by: jacek-prisma <malec@prisma.io>
e598207
to
b95bef8
Compare
Use primary key constraint rather than a unique constraint on the
(A, B)
pair in implicit m:n join tables on PostgreSQL.We gate this change to PostgreSQL only because this fixes a Postgres-specific issue with logical replication, and is not that useful for other providers, while having more complicated migration path or write performance or storage implications in other databases. On Postgres this change is fairly non-intrusive (except the one time cost of rebuilding the index and having two indexes for a short period of time).
Migrate normally generates all
ALTER TABLE
statements after theDROP INDEX
statements. To ensure the migration is safe, when we detect that a unique index is "promoted" to a primary key (in any table, not necessarily just in this case), we reorder theDROP INDEX
statement after the primary key is created. Otherwise creating the primary key may fail if non-unique records are inserted in between, since Prisma Migrate doesn't use transactions by default (except on SQL Server).Fixes: prisma/prisma#25196