Deployment issues with migrations
When I first ran the app locally, I ran wasp db migrate-dev and it created a new migration.sql file. When deploying, this new file caused issues and now there are db connectivity issues
8 Replies
Hi @joshleeman. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
It seems you're experiencing deployment issues related to database migrations in Wasp. Let's address this based on the information provided in the knowledge sources.
When you run
wasp db migrate-dev locally, it creates migration files for your local development environment. However, these migrations might not be directly applicable to your production environment, especially if you're using different database systems for development and production.
Here are a few points to consider:
1. Local vs Production Database: Wasp typically uses SQLite for local development but recommends PostgreSQL for production. If you're migrating from SQLite to PostgreSQL, you'll need to follow specific steps. Wasp docs (https://wasp-lang.dev/docs/data-model/backends#migrating-from-sqlite-to-postgresql) suggest:
- Changing the app.db.system field to PostgreSQL in your main.wasp file
- Deleting old migrations and the SQLite database
- Running wasp db migrate-dev again with the PostgreSQL database running
2. Migration Deployment: Wasp runs migrations on every application start in a deployed app. If there are new migrations, they get applied automatically. However, if migrations fail, it can lead to database connectivity issues Discord support thread (https://discord.com/channels/686873244791210014/1217295340785635418).
3. Checking Database Status: If you're experiencing connectivity issues, you might want to check the status of your production database. You can use the Fly CLI to connect to your database and inspect its contents Discord support thread (https://discord.com/channels/686873244791210014/1217295340785635418).
4. Prisma Version Compatibility: Ensure that you're using a compatible version of Prisma. Wasp has had issues in the past with Prisma version mismatches Github Issue (https://github.com/wasp-lang/wasp/issues/158).
To resolve your current issue, you might want to:
1. Verify that your production database is running and accessible.
2. Check if the migrations were applied correctly in production.
3. If necessary, consider resetting your production database and reapplying migrations.
If the problem persists, you might need to provide more detailed error logs for further diagnosis. The Wasp community on Discord is often helpful for troubleshooting deployment issues.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @joshleeman, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist:
Perhaps try again in 15mins?Can you share some more details? E.g. error messages you received?
@matijash (I am working with @joshleeman ) Basically, he ran the db migrate command locally, it created a new migration file in
migrations, then we deployed it live. However, when building, the server kept saying there was an issue with this latest migration and wouldnt build.
It didn't seem possible to revert this--I see Prisma has this functionality, but wasp docs say not to use Prisma directly. As such, I tried deleting the migration locally then deploying, but the db seemed to have saved the migration somehow. At this point, we have deleted the database entirely and created a new one, but the server is having difficulty connecting to it even tho we set the database url secret.
We are seeing this error:
@joshleeman any other details?Thanks @Trigaten for summarizing. Yup, new db was set up successfully and I thought necessary secrets were added to connect to the server, but clearly not. Any guidance in deploying the new db/server connection would be much appreciated!
@matijash does wasp allow us to revert db migrations?
Given that we deleted and recreated the db, what secrets do we need to set?
@matijash Any ideas for us to look into?
Sorry for the delay - our core team is in eu and it was a holiday yesterday. I think @miho would probably have the best idea so tagging here. Please keep in mind we dont have a dedicated support service but we will answer as soon as we can
Absolutely understood, appreciate any help yall can give 🙂
@miho @Vinny (@Wasp) might any of you be able to provide some advice on handling migrations conflicts?