Multischema configuration does not support environment variables
See original GitHub issueWhen attempting to use an environment variable to configure the schemas array in the datasource, OR the @@schema for models, the following error occurs:
Environment variables loaded from .env
Prisma schema loaded from prisma\schema.prisma
Error: Schema validation error - Error (query-engine-node-api library)
Error code: P1012
error: Expected a string value, but received functional value `env("DATABASE_SCHEMA")`.
--> schema.prisma:10
|
9 | url = env("DATABASE_URL")
10 | schemas = [env("DATABASE_SCHEMA"), "public"]
|
Validation Error Count: 1
[Context: getConfig]
Issue Analytics
- State:
- Created a year ago
- Reactions:1
- Comments:5 (2 by maintainers)
Top Results From Across the Web
Allow environment expressions inside the Prisma Schema
Problem Today we support variable expressions within the .env file: ... But we don't currently support environment expression inside the ...
Read more >47 Managing a Multischema System - Oracle Help Center
Setting Database Schema Status · Go to the BRM_home/apps/multi_db directory and open the config_dist. · Change the values in the STATUS entries: ·...
Read more >No environment variable definition found for schema name
Solved: Greetings. My setup: I am using the Azure DevOps tools for moving solutions to downstream environments (DEV > QA > PROD). In...
Read more >Handling multiple schemas in the same database with Flyway
In this post we'll talk about them as being in flyway.conf , but of course the same will apply whether you choose to...
Read more >Environment variables - Prisma
env file will automatically be loaded when running a Prisma CLI command. Do not commit your .env files into version control! Refer to...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Exactly. In this use case, schema is really treated as a part of the environment/connectionstring rather than the application.
In this case, Heroku Connect, which uses the database as a formal pass-through into Salesforce. A Heroku Connect connected database can have “copies” of the same tables which direct the bidirectional replication, each in its own schema. So instead of a traditional “app1” / “app2” schema, it’s a “dev” / “production” schema. Is there a workaround or better way you can think of to accommodate this?