Skip to main content
Module

x/kysely_deno_postgres_dialect/deps.ts>DialectAdapter

Kysely dialect for PostgreSQL using the deno-postgres client.
Latest
interface DialectAdapter
Re-export
import { type DialectAdapter } from "https://deno.land/x/kysely_deno_postgres_dialect@v0.27.1/deps.ts";

A DialectAdapter encapsulates all differences between dialects outside of Driver and QueryCompiler.

For example, some databases support transactional DDL and therefore we want to run migrations inside a transaction, while other databases don't support it. For that there's a supportsTransactionalDdl boolean in this interface.

Properties

readonly
supportsCreateIfNotExists: boolean

Whether or not this dialect supports if not exists in creation of tables/schemas/views/etc.

If this is false, Kysely's internal migrations tables and schemas are created without if not exists in migrations. This is not a problem if the dialect supports transactional DDL.

readonly
supportsTransactionalDdl: boolean

Whether or not this dialect supports transactional DDL.

If this is true, migrations are executed inside a transaction.

readonly
supportsReturning: boolean

Whether or not this dialect supports the returning in inserts updates and deletes.

Methods

acquireMigrationLock(db: Kysely<any>, options: MigrationLockOptions): Promise<void>

This method is used to acquire a lock for the migrations so that it's not possible for two migration operations to run in parallel.

Most dialects have explicit locks that can be used, like advisory locks in PostgreSQL and the get_lock function in MySQL.

If the dialect doesn't have explicit locks the MigrationLockOptions.lockTable created by Kysely can be used instead. You can access it through the options object. The lock table has two columns id and is_locked and there's only one row in the table whose id is MigrationLockOptions.lockRowId. is_locked is an integer. Kysely takes care of creating the lock table and inserting the one single row to it before this method is executed. If the dialect supports schemas and the user has specified a custom schema in their migration settings, the options object also contains the schema name in MigrationLockOptions.lockTableSchema.

Here's an example of how you might implement this method for a dialect that doesn't have explicit locks but supports FOR UPDATE row locks and transactional DDL:

{
  async acquireMigrationLock(db, options): Promise<void> {
    const queryDb = options.lockTableSchema
      ? db.withSchema(options.lockTableSchema)
      : db

    // Since our imaginary dialect supports transactional DDL and has
    // row locks, we can simply take a row lock here and it will guarantee
    // all subsequent calls to this method from other transactions will
    // wait until this transaction finishes.
    await queryDb
      .selectFrom(options.lockTable)
      .selectAll()
      .where('id', '=', options.lockRowId)
      .forUpdate()
      .execute()
  }
}

If supportsTransactionalDdl is true then the db passed to this method is a transaction inside which the migrations will be executed. Otherwise db is a single connection (session) that will be used to execute the migrations.

releaseMigrationLock(db: Kysely<any>, options: MigrationLockOptions): Promise<void>

Releases the migration lock. See acquireMigrationLock.

If supportsTransactionalDdl is true then the db passed to this method is a transaction inside which the migrations were executed. Otherwise db is a single connection (session) that was used to execute the migrations and the acquireMigrationLock call.