In CI(GitHub Actions), I want to check if schema changed without migration generated.
There is exact command what I want in Django, ./manage.py makemigrations --check, but I cannot found such command in Prisma.
https://docs.djangoproject.com/en/4.1/ref/django-admin/#cmdoption-makemigrations-check
What would be the best way to check ungenerated migration with Prisma?
Depending on what exactly you want to compare you can use prisma migrate diff for this.
prisma migrate diff --from-schema-datamodel --to-schema-datasource --exit-code
prisma migrate diff --from-migrations --to-schema-datasource --exit-code
prisma migrate diff --from-migrations --to-schema-datamodel --exit-code
This will compare the state of the two sides with each other. If they are the same it will exit with 0 if there are differences with 2.
See the command docs here: https://www.prisma.io/docs/reference/api-reference/command-reference#migrate-diff
Related
I have a prisma db and I am trying to run the deploy command for production.
When running yarn rw prisma migrate deploy , I get an error saying:
1 migration found in prisma/migrations
Error: P3005
The database schema is not empty. Read more about how to baseline an existing production database: https://pris.ly/d/migrate-baseline
What am I doing wrong and how can I fix it?
If you setted up Prisma on an existing database you must skip initial migration as such:
yarn prisma migrate resolve --applied <migration_name>
Its called baselining.
If it doesnt work due to some existing data, you can either rollback changes or fix the data problem and apply a fix with yarn prisma migrate diff
Details are here.
I ran the diff and applied the resulting file as such:
yarn prisma migrate diff --from-url <DATABASE_URL_PROD> --to-schema-datamodel <path to schema.prisma> --script > forward.sql
yarn prisma db execute --url <DATABASE_URL_PROD> --file forward.sql
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.
Given a team composed of data scientists and developers.
Developers want to use schema.prisma but data scientists don't and want to freely edit the DB directly...
What happen if a data scientist alter the DB directly? Will prisma migrate dev/deploy continue to work correctly?
If the data scientists alter the database directly then there would be a drift between the prisma schema and the database schema.
So next time when someone invokes prisma migrate dev command, prisma would prompt you to reset the database.
From Documentation:
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
It is advisable to stick to only one approach, either updating database only through migrations or just directly updating the database, combining both would lead to an undesirable state.
In addition to #Nurul Sundarani's answer, here is what I did:
$ vim .env # Points `DATABASE_URL` to the data-scientists' DB
$ npx prisma db pull # Pull changes from it and update `schema.prisma`
$ vim .env # Points `DATABASE_URL` back to localhost
$ npx prisma migrate dev # Generate the migration and apply changes tolocal DB
Name of your migration: my_sneaky_new_migration
$ git add prisma/schema.prisma prisma/migrations/20220603XXXXX_my_sneaky_new_migration
$ git commit
$ vim .env # Points `DATABASE_URL` to the data-scientists' DB
$ npx prisma migrate resolve --applied "my_sneaky_new_migration" # Mark the migration as already applied
$ vim .env # Points `DATABASE_URL` back to localhost
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/