Class MssqlAdapter

A basic implementation of DialectAdapter with sensible default values. 3rd party dialects can extend this instead of implementing the DialectAdapter interface from scratch. That way all new settings will get default values when they are added and there will be less breaking changes.




  • get 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.

    Returns boolean

  • get supportsReturning(): boolean
  • Whether or not this dialect supports the returning in inserts updates and deletes.

    Returns boolean

  • get supportsTransactionalDdl(): boolean
  • Whether or not this dialect supports transactional DDL.

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

    Returns boolean


  • 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 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 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 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
    .where('id', '=', options.lockRowId)

    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.


    Returns Promise<void>

Generated using TypeDoc