⚠️ Update: The actually implemented solution can be found here: #1487 (comment)
Context
It's a common use case to use different but very similar databases for different environments (e.g. using SQLite for local development and using Postgres in production). Prisma is especially well suited to support this use case as every Prisma connector is aware of the database's capabilities and can therefore safely (i.e. at schema validation / client generation time) determine whether two databases are compatible. It does so by reducing the supported database capabilities down to the "overlapping capabilities" (or in mathematical terms: "Lowest common denominator"). For example even though Postgres supporting scalar list fields, when a user wants to use Postgres and SQLite in the same project, the scalar list feature won't be available i.e. the schema won't validate and client operations won't be generated.
In the past we tried to solve this by supporting an optional enabled: env("SOME_VAR") (see e.g. #1142) however this solution had multiple problems such as:
- It's unintuitive how
enabled works and how it's supposed to be used. I.e. $SOME_VAR is casted to a boolean
- It's also not clear in which cases the user should configure multiple datasources for multiple environments or just replace environment variables
Proposal
Here is a quick summary of what I'm proposing. More details afterwards.
- Remove the
provider: "postgresql" property from the datasource block as it's redundant to the information contained in the url property.
- This enables datasources to become fully dynamic as they can be set via environment variables (and even allows for different datasource types e.g. dynamically switching between SQLite and Postgres).
- To still enable static schema validation, we'll introduce a
providers: ["postgresql", "sqlite"] property
Details
⚠️ Still WIP
Related issues
Context
It's a common use case to use different but very similar databases for different environments (e.g. using SQLite for local development and using Postgres in production). Prisma is especially well suited to support this use case as every Prisma connector is aware of the database's capabilities and can therefore safely (i.e. at schema validation / client generation time) determine whether two databases are compatible. It does so by reducing the supported database capabilities down to the "overlapping capabilities" (or in mathematical terms: "Lowest common denominator"). For example even though Postgres supporting scalar list fields, when a user wants to use Postgres and SQLite in the same project, the scalar list feature won't be available i.e. the schema won't validate and client operations won't be generated.
In the past we tried to solve this by supporting an optional
enabled: env("SOME_VAR")(see e.g. #1142) however this solution had multiple problems such as:enabledworks and how it's supposed to be used. I.e.$SOME_VARis casted to a booleanProposal
Here is a quick summary of what I'm proposing. More details afterwards.
provider: "postgresql"property from thedatasourceblock as it's redundant to the information contained in theurlproperty.providers: ["postgresql", "sqlite"]propertyDetails
Related issues