I keep getting the error:
Error: Invalid prisma.profile.findUnique()
invocation: error: Error validating datasource DS
: The URL for datasource DS
must start with the protocol file:
. → schema.prisma:3 | 2 | provider = “sqlite” 3 | url = env(“DATABASE_URL”) | Validation Error Count: 1
My schema.prisma file says:
datasource DS {
provider = ["sqlite", "postgresql"]
url = env("DATABASE_URL")
}
and my .env (&.env.default) files say:
# DATABASE_URL=file:./dev.db
DATABASE_URL=postgres://postgres:<omitted>@db.<omitted>.supabase.co:5432/postgres
I don’t understand what I’m missing here…
Sorry the link was wrong and the correct is Redwood v0.25.0 🚀
Hrmmm…
I had tried provider = “postgresql” first – then found the note about the array
I get the error no matter what – but I just noticed that it may be pointing at the env(“DATASOURCE_URL”) ?
api | Error:
api | Invalid `prisma.profile.findUnique()` invocation:
api |
api |
api | error: Error validating datasource `DS`: The URL for datasource `DS` must start with the protocol `file:`.
api | --> schema.prisma:3
api | |
api | 2 | provider = "sqlite"
api | 3 | url = env("DATABASE_URL")
api | |
api |
api | Validation Error Count: 1
wait – where the h*ll is it finding that schema.prisma ??
that’s not what I’m editing in my project folder…
it reading from ./node_modules/.prisma/client/schema.prisma
not from ./api/db/schema.prisma
how did I do THAT ?
One thing you should do is to check your redwood.toml file since the path to the schema file is in there and be sure to regenerate your Prisma client via ‘yarn rw prisma generate’.
The path to the schema was changed in an earlier release so if you have upgraded from a mid 20s version it could be different.
hrm… (again)
this project was generated 0.31 & upgraded to 0.32
yarn rw prisma generate
- no joy…
redwood.toml
[web]
port = 8910
apiProxyPath = "/.netlify/functions"
includeEnvironmentVariables = ['SUPABASE_URL', 'SUPABASE_KEY']
[api]
port = 8911
schemaPath = "./api/db/schema.prisma"
[browser]
open = true
wait – found another anomaly
ok, too many terminal sessions
I was running the playground-auth in another session on different port #'s (how easy was that !!!
when I ran the yarn rw prisma generate
this time it fixed the problem – and complained
warn Versions of prisma@2.23.0 and @prisma/client@2.22.1 don't match.
This might lead to unexpected behavior.
Please make sure they have the same version.
the [project root] package.json references prisma thusly "prisma": "^2.22.1"
in order to make it work
I had to use postgresql instead of postgres in the DATABASE_URL
(where it === use my supabase postgres database)
Correct - as per the v0.25 info here:
You can no longer use both SQLite and Postgres at the same time, which previously was set in schema.prisma
as provider = ["sqlite", "postgresql"]
. From here on out you’ll have to make a choice
And then copy the proper connection string from your Supabase dashboard UI.
The connection string from Supabase was postgres://postgres:[YOUR-PASSWORD]@db.scbqrtiao...
I had to use DATABASE_URL=postgresql://postgres:Bk9...
It wasn’t what they had in the dashboard, but it’s what worked for me – whew!
I have been at this for some time now…
I had installed
7/28/21
My solution:
redwood.toml
[api]
port = 8911
schemaPath = "./api/db/schema.prisma"
schema.prisma
datasource db {
provider = "postgresql"
url = env("DATABASE_URL")
}
.env
DATABASE_URL=postgresql://{system_username}:{system_password}@postgresql:admin@localhost:5432
1 Like
Thanks! I’ve been wanting a local instance !!
Now to mock Supabase in development and I can finally work offline !!
Well, this is annoying. I’m using a postgresql instance on DigitalOcean, so my url looks like this…
DATABASE_URL=postgresql://doadmin:mR…
With a “doadmin” command rather than “postgres” or “postgresql”. And if I change it, the url doesn’t authenticate. But this causes my Redwood tests to error out. Sigh. I suppose I’ll have to find another db host with a more regular url form.
Hi @dstagner the “doadmin” is the username for the username and password (username:password) part of the connection strings.
I am guessing that if you change that then you likely cannot access your database due to invalid credentials.