Skip to content
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

Prisma join tables unable to be replicated by default #25196

Open
sdgluck opened this issue Sep 9, 2024 · 1 comment · May be fixed by prisma/prisma-engines#5051 or prisma/prisma-engines#5057
Open
Assignees
Labels
bug/2-confirmed Bug has been reproduced and confirmed. domain/schema Issue in the "Schema" domain: Prisma Schema, Introspection, Migrations etc. kind/bug A reported bug. topic: breaking change topic: read replica

Comments

@sdgluck
Copy link

sdgluck commented Sep 9, 2024

Bug description

(Creating an issue from my comment on this closed issue.)

Due to Prisma relation tables not having a primary key and due to the default replica identity behaviour these tables are not able to be replicated without further manual configuration.

Prisma relation tables use a unique index on the two columns A and B and so theoretically the REPLICA IDENTITY FULL should be able to perform without issue as this constraint will prevent duplicate records which would impact data consistency.

I see a few options for a resolution:

  1. include ALTER TABLE x REPLICA IDENTITY FULL in the SQL for creation of these tables in migrations
  2. add a primary key on relation tables
  3. provide replica identity configuration within the Prisma schema DSL

My preference would be 2 as it is the least effort (for users and Prisma devs) and means future join table schemas will not diverge from the current schema.

How to reproduce

  • Create a join table via eg. many-to-many relation in a Prisma schema
  • Configure logical replication for the Postgres schema
  • Notice error in logs "...because it does not have a replica identity and publishes deletes..."

Expected behavior

I would expect Prisma would make some consideration for the scenario of logical replication of join tables such that this error does not occur.

Prisma information

n/a

Environment & setup

  • OS: macOS
  • Database: PostgreSQL
  • Node.js version: 20

Prisma Version

prisma                  : 5.10.2
@prisma/client          : 5.10.2
Computed binaryTarget   : darwin
Operating System        : darwin
Architecture            : x64
Node.js                 : v20.14.0
Query Engine (Node-API) : libquery-engine 5a9203d0590c951969e85a7d07215503f4672eb9 (at ../../node_modules/@prisma/engines/libquery_engine-darwin.dylib.node)
Schema Engine           : schema-engine-cli 5a9203d0590c951969e85a7d07215503f4672eb9 (at ../../node_modules/@prisma/engines/schema-engine-darwin)
Schema Wasm             : @prisma/prisma-schema-wasm 5.10.0-34.5a9203d0590c951969e85a7d07215503f4672eb9
Default Engines Hash    : 5a9203d0590c951969e85a7d07215503f4672eb9
Studio                  : 0.499.0
Preview Features        : metrics, views
@sdgluck sdgluck added the kind/bug A reported bug. label Sep 9, 2024
@jkomyno jkomyno added domain/schema Issue in the "Schema" domain: Prisma Schema, Introspection, Migrations etc. topic: read replica labels Sep 9, 2024
@jkomyno
Copy link
Contributor

jkomyno commented Sep 9, 2024

Hi @sdgluck, thanks for opening this issue, explaining your use case and proposing more than one possible solution.
Replica scenarios are currently under-investigated in Prisma, and adding a Primary Key to relation tables seems like an adequate solution.

Doing so would probably require a new major version though, as it would modify the generated migrations. We'll follow up on this, thanks for your input!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug/2-confirmed Bug has been reproduced and confirmed. domain/schema Issue in the "Schema" domain: Prisma Schema, Introspection, Migrations etc. kind/bug A reported bug. topic: breaking change topic: read replica
Projects
None yet
2 participants