"Deployment" section is incomplete and dead-end: cannot deploy as-is
thedavidprice opened this issue · 8 comments
It's a Catch 22 — we need to delete migrations/, change provider to postgres, and then create a new migration. However, we need to set the local DB connection env var DATABASE_URL to a functional postgres instance, which would mean setting up a local postgres. I think I found a hacky way to do it.
If the reader has postgres installed locally, use that
For people who know what they're doing, the best path forward is to use a local postgres DB. We should suggest that.
Use the Cloud Hosted DB and --create-only
Because of Prisma Shadow DB 😈 craziness, using a hosted DB for local dev actually requires two DBs: one for dev and the other as a Shadow DB used during migration creation for a kind of verify-before-apply.
HOWEVER, this works (it's just brittle and not to be messed up):
- delete migrations/ and set the datasource as postgres
- create the hosted postgres and get the connection string
- then use that connection string in .env DATABASE_URL
- and then run
rw prisma migrate dev --create-only
And it Works™, even without the shadow DB.
We need to explain this is a workaround for quick Tutorial experience. The right way is to create an actual local dev DB (see doc). If they mess things up, e.g. apply to hosted DB, they could 1) delete migrations/ and then 2) run rw prisma migrate reset
which seems to do the trick.
This needs to be tested. But I think it's a way forward.
FWIW - I was expecting it to break locally when I switched to the Railway in the tutorial, but just wanted to see it work in a live environment. I knew I would have to do some extra setup work to get it working locally again because of the warning you have in there. But I was confused when it didn't deploy after I followed the steps outlined to switch to postgres.
If you do —create-only
do you even need a real database running somewhere, or does Prisma just pull the provider part out of the DATABASE_URL
string so it know which syntax to use? Meaning, could we have everyone just put something like postgres://localhost/test
in there, even if they don’t have it running locally, but it’ll give prisma enough to create the migrations?
Looks like it needs a db running
#.env
# schema.prisma defaults
DATABASE_URL="postgresql://postgres@localhost/test"
➜ whenarethefights.com git:(master) ✗ yarn rw prisma migrate dev --create-only
yarn run v1.22.10
$ .../node_modules/.bin/rw prisma migrate dev --create-only
Running Prisma CLI:
yarn prisma migrate dev --create-only --schema "...whenarethefights.com/api/db/schema.prisma"
Prisma schema loaded from db/schema.prisma
Datasource "DS": PostgreSQL database "test", schema "public" at "localhost:5432"
Error: P1001: Can't reach database server at `localhost`:`5432`
Please make sure your database server is running at `localhost`:`5432`.
Hmmm so the flag named "create-only" seems to be misleading. 😐
Check this --> I went through this with some folks from Prisma this morning and we currently think it's actually that Railway might not require setting up a separate hosted DB as a shadow database. Ran through the flow a few times again and it's working.
TBD
I want to update the deployment section to use render.com—SQLite from beginning to end! I'm thinking once dbAuth merges I can update the Authentication section at the same time, greatly simplifying the last 1/4 or so of the tutorial. Just in time for 1.0 and re-recording my videos!
OH, super interesting ideas, RC. If you move in that direction, let's talk to Render about 2 items:
- improving their support for SQLite --> I've noticed on re-deployment that my DB connection fails. I have to manually re-trigger to get it working again.
- Render currently only offers a 7-day free trial --> do you think this is adequate for the Tutorial (including part 2?) and/or should we see if they'd consider extending it or offering some kind of code to give Redwood users extended time. TBD
That would be awesome if they'd give us more time! But really part 2 can happen all on your dev machine, there's nothing deploy-specific in that one.
But it would be nice if your site kept running and you could deploy your new comments engine...