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
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.
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'd like to make a migration for a Flask app. I am using Alembic.
However, I receive the following error.
Target database is not up to date.
Online, I read that it has something to do with this.
http://alembic.zzzcomputing.com/en/latest/cookbook.html#building-an-up-to-date-database-from-scratch
Unfortunately, I don't quite understand how to get the database up to date and where/how I should write the code given in the link.
After creating a migration, either manually or as --autogenerate, you must apply it with alembic upgrade head. If you used db.create_all() from a shell, you can use alembic stamp head to indicate that the current state of the database represents the application of all migrations.
This Worked For me
$ flask db stamp head
$ flask db migrate
$ flask db upgrade
My stuation is like this question, When I execute "./manage.py db migrate -m 'Add relationship'", the error occused like this "
alembic.util.exc.CommandError: Target database is not up to date."
So I checked the status of my migrate:
(venv) ]#./manage.py db heads
d996b44eca57 (head)
(venv) ]#./manage.py db current
INFO [alembic.runtime.migration] Context impl SQLiteImpl.
INFO [alembic.runtime.migration] Will assume non-transactional DDL.
715f79abbd75
and found that the heads and the current are different!
I fixed it by doing this steps:
(venv)]#./manage.py db stamp heads
INFO [alembic.runtime.migration] Context impl SQLiteImpl.
INFO [alembic.runtime.migration] Will assume non-transactional DDL.
INFO [alembic.runtime.migration] Running stamp_revision 715f79abbd75 -> d996b44eca57
And now the current is same to the head
(venv) ]#./manage.py db current
INFO [alembic.runtime.migration] Context impl SQLiteImpl.
INFO [alembic.runtime.migration] Will assume non-transactional DDL.
d996b44eca57 (head)
And now I can do the migrate again.
This can be solved bby many ways :
1 To fix this error, delete the latest migration file ( a python file) then try to perform a migration afresh.
If issue still persists try these commands :
$ flask db stamp head # To set the revision in the database to the head, without performing any migrations. You can change head to the required change you want.
$ flask db migrate # To detect automatically all the changes.
$ flask db upgrade # To apply all the changes.
$ flask db stamp head # To set the revision in the database to the head, without performing any migrations. You can change head to the required change you want.
$ flask db migrate # To detect automatically all the changes.
$ flask db upgrade # To apply all the changes.
You can find more info at the documentation https://flask-migrate.readthedocs.io/en/latest/
I had to delete some of my migration files for some reason. Not sure why. But that fixed the problem, kind of.
One issue is that the database ends up getting updated properly, with all the new tables, etc, but the migration files themselves don't show any changes when I use automigrate.
If someone has a better solution, please let me know, as right now my solution is kind of hacky.
I did too run into different heads and I wanted to change one of the fields from string to integer, so first run:
$ flask db stamp head # to make the current the same
$ flask db migrate
$ flask db upgrade
It's solved now!
To fix this error, delete the latest migration file ( a python file) then try to perform a migration afresh.
This can also happen if you, like myself, have just started a new project and you are using in-memory SQLite database (sqlite:///:memory:). If you apply a migration on such a database, obviously the next time you want to say auto-generate a revision, the database will still be in its original state (empty), so alembic will be complaining that the target database is not up to date. The solution is to switch to a persisted database.
I also had the same problem input with flask db migrate
I used
flask db stamp head
and then
flask db migrate
Try to drop all tables before execute the db upgrade command.
To solve this, I drop(delete) the tables in migration and run these commands
flask db migrate
and
flask db upgrade