You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 10, 2024. It is now read-only.
This is similar to #40 but would be tailored to Postgres specifically. The idea would be to leverage SET schema or SET search_path inside of a PrismaClient middleware. The tenant model would need a schema property, and ideally this would support creating/using a different user per schema for improved data isolation and security.
Right now we can use Postgres schemas via different connection urls, but I suspect that's also spinning up a separate connection pool per schema which can be mitigated by leveraging SET schema.
The text was updated successfully, but these errors were encountered:
Nevermind, I don't believe this is possible with the current middleware support. I've opened prisma/prisma#3968. Hopefully they'll support it or provide an alternative workaround.
Hi @jimsimon! This sounds indeed like a good idea, but I don't think it's possible with the current capabilities of Prisma at the moment. I'll close this issue for now, but don't hesitate to reopen, or create a new one, if it becomes possible in the future.
This is similar to #40 but would be tailored to Postgres specifically. The idea would be to leverage
SET schema
orSET search_path
inside of a PrismaClient middleware. The tenant model would need aschema
property, and ideally this would support creating/using a different user per schema for improved data isolation and security.Right now we can use Postgres schemas via different connection urls, but I suspect that's also spinning up a separate connection pool per schema which can be mitigated by leveraging
SET schema
.The text was updated successfully, but these errors were encountered: