I have a PostgreSQL db that is used by a Nest.Js / Prisma app.
We changed the name of a field in the Prisma schema and added a new field.
Now, when we want to update the PostreSQL structure, I'm running, as suggested by Prisma, the following commands:
npx prisma generate
and then
npx prisma migrate dev --name textSettings-added --create-only
The idea is to use the --create-only flag to review the migration before it is actually made.
However, when I run it I get a list of the changes to be made to the DB and the following message:
We need to reset the PostgreSQL database "my_database" at "my_db_name#cluster.us-east-1.rds.amazonaws.com:5432".
Do you want to continue? All data will be lost.
Of course I choose not to continue, because I don't want to lose the data. Upon inspection I see that the migration file actually contains DROP TABLE for the tables that I simply wanted to modify. How to avoid that?
So how do I run the update without affecting the data?
UPDATE:
I saw that running with --create-only creates a migration which can then be implemented on the DB level using prisma migrate dev, however, in that migration file there are still some commands that drop my previous tables because of some new parameters inside. How can I run prisma migration without deleting my PostgreSQL data?
UPDATE 2:
I don't want Prisma to drop my tables when I just updated them. The migration file generated, however, drops them and then alters them. Do you know what's the best procedure to avoid this drop? I saw somewhere I could first manually update the DB with the new options and then run the migration, so Prisma can find a way to update it, but that seems too manual to me... Maybe some other ideas?
For some cases like renaming tables or columns, Prisma's generated migration files need to be updated if they already contain data.
If that applies to your use case, Prisma's docs suggest to:
Make updates to the prisma schema
Create migration file without applying it (--create-only flag)
Update the migration script to remove the drops and instead write your custom query (e.g. RENAME <table_name> TO <new_name>)
Save and apply the migration (npx prisma migrate dev)
Note that those changes can lead to downtime (renaming a field or model), for which they have outlined the expand and contract pattern.
It might be a Prisma bug: https://github.com/prisma/prisma/issues/8053
I also recently had this situation. It probably should not try to run migration if you only want to create migration file.
But overall it is expected with Prisma to recreate your db sometimes. If you migration is breaking then it will be required to reset the data anyway when you apply it.
I suggest you to create some seeding script so you could consistently re-create the database state, it's very useful for your development environment.
More info
Related
How can make a change to the database with Prisma.js without having to reset the whole thing?
When I changed prisma.schema and run:
npx prisma migrate dev --name change-name
My database lost all data. Can I run another command which doesn't remove my data? What is best for me in this situation?
You would need to Baseline your database in order to not reset your database.
For the cases which contains data that must be maintained (like production), which means that the database cannot be reset, In those cases Baselining tells Prisma Migrate to assume that one or more migrations have already been applied. This prevents generated migrations from failing when they try to create tables and fields that already exist.
When I changed prisma.schema and run:
npx prisma migrate dev --name init
My Postgres lost all data. Can I run another command which doesn't remove my data? What is best for me in this situation?
From the prisma.io documentation:
Prisma Migrate is an imperative database schema migration tool that enables you to keep your database schema in sync with your Prisma schema as it evolves and
main existing data in your database
Prisma Migrate generates a history of .sql migration files, and plays a role in both development and deployment.
This means that the prisma migrate command is supposed to be syncing the data from the model with the one in the database, adding/removing rows if needed, etc.
Perhaps the command you are looking for is prisma db push? They both have similar uses and aspects, one is for dev, one isn't.
what is the difference between prisma db push and prisma migrate dev ? When should I use one over the other. Docs say that prisma db push is about schema prototyping only and I don't understand what does that mean.
They serve two different environments. The prisma db push is not to be used in your production environment, as stated in the docs
db push uses the same engine as Prisma Migrate to synchronize your Prisma schema with your database schema, and is best suited for schema
prototyping. The db push command:
Introspects the database to infer and executes the changes required to
make your database schema reflect the state of your Prisma schema.
By default, after changes have been applied to the database schema,
generators are triggered (for example, Prisma Client). You do not need
to manually invoke prisma generate.
If db push anticipates that the changes could result in data loss, it
will:
Throw an error
Require the --accept-data-loss option if you still want
to make the changes
Note: db push does not interact with or rely on
migrations. The migrations table will not be updated, and no migration
files will be generated.
The prisma migrate dev is used in you local environment, as explained in the docs
migrate dev is a development command and should never be used in a
production environment.
This command:
Replays the existing migration history in the shadow database in order
to detect schema drift (edited or deleted migration file, or a manual
changes to the database schema)
Applies pending migrations to the
shadow database (for example, new migrations created by colleagues)
Generates a new migration from any changes you made to the Prisma
schema before running migrate dev
Applies all unapplied migrations to
the development database and updates the _prisma_migrations table
Triggers the generation of artifacts (for example, the Prisma Client)
The migrate dev command will prompt you to reset the database in the
following scenarios:
Migration history conflicts caused by modified or missing migrations
The database schema has drifted away from the end-state of the
migration history
If you have any other question regarding this, there is this comparison in the docs explaining when to use one or the other.
From the docs:
Use db push to prototype a schema at the start of a project and initialize a migration history when you are happy with the first draft
Use db push to prototype a change to an existing schema, then run prisma migrate dev to generate a migration from your changes (you will be asked to reset)
So the key for me here, was that only the first time I had to run db push (into a heroku app with heroku postgres). After that, migrations all the time...
I'm new to Prisma ORM, & I'm trying to make migrations in Prisma
I see that I way to do this is to update data.model & then just run:
prisma deploy
But what if I want to create a migrations for specific versions of app how could I do that ??
As the prisma documentation describes there are two ways of doing database migrations in prisma:
Using the Prisma CLI
Performing a manual DB migration with plain SQL
If you follow the first approach and edit your data model the changes will be carried out automagically once you run prisma deploy. You can specify the service and stage this will be rolled out to via the PRISMA_ENDPOINT environment variable:
PRISMA_ENDPOINT="http://localhost:4466/{SERVICE}/{STAGE}"
This way you can roll out and test you data model changes in a different stage or on a different service.
The second approach is to manually change the database model via plain SQL. Be careful to ensure the database schema and your data model are in sync.
For more information check out:
https://www.prisma.io/docs/datamodel-and-migrations/migrations-POSTGRES-asd4/
I used prisma to generate the schema to a database, but due to changing an id column started getting errors. I deleted the tables and was going to redeploy the schema but I can't find a way to do that.
I've already tried doing things like prisma deploy, but it tells me I'm already sync'd up which isn't true. I need it to redeploy as if the schema was new and it seems to not want to do that.
TL;DR: Try prisma delete then prisma deploy.
Prisma create a database for management where it will hold all migration related data. Even if you deleted the tables manually, you didn't change the migration data about your service. Therefore, Prisma think everything is up-to-date.
Instead of manually deleting the tables, you should use prisma delete to let Prisma do a clean deleting of your tables. Then, you can re-run prisma deploy to rebuild the tables again.
Give this a try: "prisma deploy --force"
According to the documentation you have to accept data loss caused by schema changes with --force. But the tables are already deleted in your case, so I think it is ok to try it.
Prisma doc