migrations feature for
will cause the generated client to expose some methods for using Prisma's
migration engine (opens in a new tab).
Specifically, the Prisma CLI's
migrate deploy and
migrate resolve functions will have equivalent functions in the client.
Using the migration engine in this way is not recommended unless you can't use the Prisma CLI, such as for desktop apps (like those built with Tauri (opens in a new tab)) and server deployments where the CLI is not available. When the CLI is available, use it manually or in CI to deploy migrations.
While modifying your Prisma schema use
PrismaClient::_db_push to synchronize your database and schema.
As explained in Prisma's docs (opens in a new tab), this does not use migrations,
instead it pushes the state of your schema directly to the database.
_db_push returns a builder than has additional functions specifying additional options that are available in the CLI:
client ._db_push() .accept_data_loss() // --accept-data-loss in CLI .force_reset() // --force-reset in CLI .await?;
After you have finalised your schema changes and generated migrations via the CLI,
PrismaClient::_migrate_deploy to apply all pending migrations with the migration engine
(Prisma docs (opens in a new tab)).
Prisma provides the ability to baseline existing database in order to make them compatible with Prisma migrate. The baselining process will not be detailed here as the Prisma docs (opens in a new tab) already do a great job explaining it.
PrismaClient::_migrate_resolve is available as an in-code alternative to the CLI's
migrate resolve command. It requires specifying a migration name as its first argument.
client ._migrate_resolve("20210426141759_initial-migration-for-db") .await?;
The following migration setup may be used in a new application using Prisma Client Rust. Baselining is not necessary as the database will not have existing migrations.
_db_push will be used to synchronize the schema and database without generating migrations.
It may be necessary to occasionally add
force_reset if major changes are made to your schema.
It is necessary to generate migrations using the CLI's
migrate dev command once schema changes are finalized
When the application is ran in release mode,
_migrate_deploy will be used to apply all migrations generated by
#[cfg(debug_assertions)] client._db_push().await?; #[cfg(not(debug_assertions))] client._migrate_deploy().await?;
For a project switching from using another ORM or raw SQL a similar approach to new projects can be taken, but baselining (opens in a new tab) must be done.
After introspecting your database schema into a
generate the initial migration with
then use that migration's name in
_migrate_resolve before applying further migrations.
client ._migrate_resolve("INITIAL MIGRATION NAME") .await?; #[cfg(debug_assertions)] client._db_push().await?; #[cfg(not(debug_assertions))] client._migrate_deploy().await?;