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.
Whether or not this dialect supports the returning
in inserts
updates and deletes.
Whether or not this dialect supports transactional DDL.
If this is true, migrations are executed inside a transaction.
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
.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.
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.
Generated using TypeDoc
A basic implementation of
DialectAdapter
with sensible default values. 3rd party dialects can extend this instead of implementing theDialectAdapter
interface from scratch. That way all new settings will get default values when they are added and there will be less breaking changes.