feat(schema-engine): use pk for implicit join tables on postgres#5057
Merged
feat(schema-engine): use pk for implicit join tables on postgres#5057
Conversation
CodSpeed Performance ReportMerging #5057 will not alter performanceComparing Summary
|
Contributor
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
jkomyno
reviewed
Nov 28, 2024
Comment on lines
+551
to
+554
| // 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. |
Contributor
There was a problem hiding this comment.
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.
Co-authored-by: jacek-prisma <malec@prisma.io>
e598207 to
b95bef8
Compare
jacek-prisma
approved these changes
Nov 28, 2024
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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 TABLEstatements after theDROP INDEXstatements. 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 INDEXstatement 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