Module schema_core::json_rpc

The JSON-RPC API definition.

Methods

🔌 applyMigrations

➡️ ApplyMigrationsInput

↩️ ApplyMigrationsOutput

Apply the migrations from the migrations directory to the database.

This is the command behind prisma migrate deploy.

🔌 createDatabase

➡️ CreateDatabaseParams

↩️ CreateDatabaseResult

Create the logical database from the Prisma schema.

🔌 createMigration

➡️ CreateMigrationInput

↩️ CreateMigrationOutput

Create the next migration in the migrations history. If draft is false and there are no unexecutable steps, it will also apply the newly created migration.

Note: This will use the shadow database on the connectors where we need one.

🔌 dbExecute

➡️ DbExecuteParams

↩️ DbExecuteResult

Execute a database script directly on the specified live database.

Note that this may not be defined on all connectors.

🔌 debugPanic

➡️ DebugPanicInput

↩️ DebugPanicOutput

Make the schema engine panic. Only useful to test client error handling.

🔌 devDiagnostic

➡️ DevDiagnosticInput

↩️ DevDiagnosticOutput

The method called at the beginning of migrate dev to decide the course of action based on the current state of the workspace.

It acts as a wrapper around diagnoseMigrationHistory. Its role is to interpret the diagnostic output, and translate it to a concrete action to be performed by the CLI.

🔌 diagnoseMigrationHistory

➡️ DiagnoseMigrationHistoryInput

↩️ DiagnoseMigrationHistoryOutput

Read the contents of the migrations directory and the migrations table, and returns their relative statuses. At this stage, the migration engine only reads, it does not write to the database nor the migrations directory, nor does it use a shadow database.

🔌 diff

➡️ DiffParams

↩️ DiffResult

Compares two databases schemas from two arbitrary sources, and display the difference as either a human-readable summary, or an executable script that can be passed to dbExecute.

Connection to a shadow database is only necessary when either the from or the to params is a migrations directory.

Diffs have a direction. Which source is from and which is to matters. The resulting diff should be thought as a migration from the schema in from to the schema in to.

By default, we output a human-readable diff. If you want an executable script, pass the "script": true param.

🔌 ensureConnectionValidity

➡️ EnsureConnectionValidityParams

↩️ EnsureConnectionValidityResult

Make sure the schema engine can connect to the database from the Prisma schema.

🔌 evaluateDataLoss

➡️ EvaluateDataLossInput

↩️ EvaluateDataLossOutput

Development command for migrations. Evaluate the data loss induced by the next migration the engine would generate on the main database.

At this stage, the engine does not create or mutate anything in the database nor in the migrations directory.

This is part of the migrate dev flow.

Note: the engine currently assumes the main database schema is up-to-date with the migration history.

🔌 getDatabaseVersion

➡️ GetDatabaseVersionInput

↩️ GetDatabaseVersionOutput

Get the database version for error reporting.

🔌 introspect

➡️ IntrospectParams

↩️ IntrospectResult

Introspect the database (db pull)

🔌 listMigrationDirectories

➡️ ListMigrationDirectoriesInput

↩️ ListMigrationDirectoriesOutput

List the names of the migrations in the migrations directory.

🔌 markMigrationApplied

➡️ MarkMigrationAppliedInput

↩️ MarkMigrationAppliedOutput

Mark a migration as applied in the migrations table.

There are two possible outcomes:

• The migration is already in the table, but in a failed state. In this case, we will mark it as rolled back, then create a new entry.
• The migration is not in the table. We will create a new entry in the migrations table. The started_at and finished_at will be the same.
• If it is already applied, we return a user-facing error.

🔌 markMigrationRolledBack

➡️ MarkMigrationRolledBackInput

↩️ MarkMigrationRolledBackOutput

Mark an existing failed migration as rolled back in the migrations table. It will still be there, but ignored for all purposes except as audit trail.

🔌 reset

➡️ ResetInput

↩️ ResetOutput

Try to make the database empty: no data and no schema. On most connectors, this is implemented by dropping and recreating the database. If that fails (most likely because of insufficient permissions), the engine attemps a “best effort reset” by inspecting the contents of the database and dropping them individually.

Drop and recreate the database. The migrations will not be applied, as it would overlap with applyMigrations.

🔌 schemaPush

➡️ SchemaPushInput

↩️ SchemaPushOutput

The command behind db push.

Modules

• method_names
  String constants for method names.
• types
  API type definitions used by the methods.