noormme 1.0.0

package/dist/cjs/cli/index.js

@@ -0,0 +1,157 @@
+#!/usr/bin/env node
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+const commander_1 = require("commander");
+const chalk_1 = require("chalk");
+const init_js_1 = require("./commands/init.js");
+const inspect_js_1 = require("./commands/inspect.js");
+const generate_js_1 = require("./commands/generate.js");
+const optimize_js_1 = require("./commands/optimize.js");
+const analyze_js_1 = require("./commands/analyze.js");
+const migrate_js_1 = require("./commands/migrate.js");
+const watch_js_1 = require("./commands/watch.js");
+const status_js_1 = require("./commands/status.js");
+const program = new commander_1.Command();
+program
+    .name('noormme')
+    .description(chalk_1.default.blue.bold('NOORMME CLI - Automating SQLite with Intelligence'))
+    .version('1.0.0');
+// Init command - Zero-configuration setup
+program
+    .command('init')
+    .description('Initialize NOORMME with zero-configuration SQLite automation')
+    .option('-d, --database <path>', 'SQLite database file path', './database.sqlite')
+    .option('-o, --output <dir>', 'Output directory for generated files', 'lib')
+    .option('-f, --force', 'Overwrite existing files')
+    .option('--no-auto-optimize', 'Disable automatic SQLite optimization')
+    .option('--no-auto-index', 'Disable automatic index recommendations')
+    .action(init_js_1.init);
+// Inspect command - Enhanced schema discovery
+program
+    .command('inspect [table]')
+    .description('Inspect database schema with automation insights')
+    .option('-d, --database <path>', 'SQLite database file path')
+    .option('-r, --relationships', 'Show relationships and foreign keys')
+    .option('-o, --optimizations', 'Show optimization recommendations')
+    .option('-i, --indexes', 'Show index analysis')
+    .option('-p, --performance', 'Show performance metrics')
+    .action(inspect_js_1.inspect);
+// Generate command - Enhanced type and repository generation
+program
+    .command('generate')
+    .description('Generate TypeScript types, repositories, and automation files')
+    .option('-d, --database <path>', 'SQLite database file path')
+    .option('-o, --output <dir>', 'Output directory', './generated')
+    .option('-t, --types-only', 'Generate only TypeScript types')
+    .option('-r, --repos-only', 'Generate only repository classes')
+    .option('-f, --format <format>', 'TypeScript output format (dts, ts)', 'dts')
+    .action(generate_js_1.generate);
+// Optimize command - SQLite performance optimization
+program
+    .command('optimize')
+    .description('Optimize SQLite database performance automatically')
+    .option('-d, --database <path>', 'SQLite database file path')
+    .option('-p, --pragma', 'Apply PRAGMA optimizations')
+    .option('-i, --indexes', 'Apply intelligent index recommendations')
+    .option('-a, --analyze', 'Run ANALYZE for query optimization')
+    .option('-w, --wal', 'Enable WAL mode for better concurrency')
+    .option('--dry-run', 'Show what would be optimized without applying changes')
+    .action(optimize_js_1.optimize);
+// Analyze command - Query pattern analysis
+program
+    .command('analyze')
+    .description('Analyze query patterns and provide intelligent recommendations')
+    .option('-d, --database <path>', 'SQLite database file path')
+    .option('-s, --slow-queries', 'Focus on slow query analysis')
+    .option('-i, --indexes', 'Generate index recommendations')
+    .option('-p, --patterns', 'Show query usage patterns')
+    .option('-r, --report', 'Generate detailed performance report')
+    .action(analyze_js_1.analyze);
+// Migrate command - Automated migration management
+program
+    .command('migrate')
+    .description('Manage database migrations with automation')
+    .option('-d, --database <path>', 'SQLite database file path')
+    .option('--to <version>', 'Migrate to specific version')
+    .option('--latest', 'Migrate to latest version')
+    .option('--rollback', 'Rollback last migration')
+    .option('--status', 'Show migration status')
+    .option('--generate <name>', 'Generate new migration')
+    .action(migrate_js_1.migrate);
+// Watch command - Schema monitoring and auto-optimization
+program
+    .command('watch')
+    .description('Monitor database schema changes and auto-optimize')
+    .option('-d, --database <path>', 'SQLite database file path')
+    .option('-i, --interval <ms>', 'Check interval in milliseconds', '5000')
+    .option('--auto-optimize', 'Automatically apply optimizations')
+    .option('--auto-index', 'Automatically apply index recommendations')
+    .option('--notify', 'Show desktop notifications for changes')
+    .action(watch_js_1.watch);
+// Status command - Automation status and metrics
+program
+    .command('status')
+    .description('Show NOORMME automation status and database metrics')
+    .option('-d, --database <path>', 'SQLite database file path')
+    .option('-m, --metrics', 'Show detailed performance metrics')
+    .option('-o, --optimizations', 'Show applied optimizations')
+    .option('-c, --cache', 'Show cache statistics')
+    .action(status_js_1.status);
+// Help command
+program.addHelpText('after', `
+${chalk_1.default.blue.bold('🚀 NOORMME - Complete SQLite Automation')}
+
+${chalk_1.default.green.bold('Quick Start:')}
+  $ noormme init                          # Zero-config setup with your existing SQLite database
+  $ noormme inspect                       # Discover your database schema automatically
+  $ noormme optimize                      # Automatically optimize SQLite performance
+
+${chalk_1.default.green.bold('Automation Features:')}
+  $ noormme analyze                       # Analyze query patterns and get recommendations
+  $ noormme migrate --latest              # Automated migration management
+  $ noormme watch --auto-optimize         # Monitor and auto-optimize continuously
+  $ noormme status                        # View automation status and metrics
+
+${chalk_1.default.green.bold('Development:')}
+  $ noormme generate                      # Generate TypeScript types and repositories
+  $ noormme inspect users --optimizations # Inspect table with optimization insights
+  $ noormme analyze --slow-queries        # Focus on performance bottlenecks
+
+${chalk_1.default.green.bold('Zero Configuration:')}
+  NOORMME automatically:
+  ✅ Discovers all tables, columns, and relationships
+  ✅ Generates TypeScript interfaces with full type safety
+  ✅ Creates repository classes with intelligent CRUD methods
+  ✅ Optimizes SQLite performance with PRAGMA settings
+  ✅ Recommends indexes based on your query patterns
+  ✅ Validates and fixes foreign key constraints
+
+${chalk_1.default.yellow('Environment Variables:')}
+  DATABASE_PATH    SQLite database file path (default: ./database.sqlite)
+
+${chalk_1.default.yellow('Pro Tips:')}
+  • Point NOORMME at your existing SQLite database - no setup required!
+  • Use --dry-run with optimize to see what would be improved
+  • Enable watch mode for continuous optimization during development
+  • Check status regularly to monitor automation effectiveness
+
+${chalk_1.default.blue('📚 Learn more: https://github.com/noormme/noormme')}
+`);
+// Error handling
+program.configureOutput({
+    writeErr: (str) => process.stderr.write(chalk_1.default.red(str))
+});
+// Handle unknown commands
+program.on('command:*', function (operands) {
+    console.error(chalk_1.default.red(`❌ Unknown command: ${operands[0]}`));
+    console.error(chalk_1.default.gray('See --help for a list of available commands.'));
+    process.exit(1);
+});
+// Parse command line arguments
+program.parse();
+// Show help if no command provided
+if (!process.argv.slice(2).length) {
+    console.log(chalk_1.default.blue.bold('\n🎯 NOORMME - Automating SQLite with Intelligence\n'));
+    console.log(chalk_1.default.gray('The only SQLite ORM that automates everything. Built on Kysely\'s type-safe foundation.\n'));
+    program.outputHelp();
+}

package/dist/cjs/dialect/database-introspector.d.ts

@@ -0,0 +1,61 @@
+import type { Kysely } from '../kysely.js';
+export interface SchemaMetadata {
+    name: string;
+}
+export interface TableMetadata {
+    name: string;
+    schema?: string;
+}
+export interface ColumnMetadata {
+    name: string;
+    type: string;
+    nullable: boolean;
+    defaultValue?: any;
+    isPrimaryKey: boolean;
+    isAutoIncrement: boolean;
+    maxLength?: number;
+    precision?: number;
+    scale?: number;
+}
+export interface IndexMetadata {
+    name: string;
+    columns: string[];
+    unique: boolean;
+}
+export interface ForeignKeyMetadata {
+    name: string;
+    column: string;
+    referencedTable: string;
+    referencedColumn: string;
+    onDelete?: 'CASCADE' | 'SET NULL' | 'RESTRICT' | 'NO ACTION';
+    onUpdate?: 'CASCADE' | 'SET NULL' | 'RESTRICT' | 'NO ACTION';
+}
+export interface DatabaseMetadataOptions {
+    withInternalKyselyTables?: boolean;
+}
+export interface DatabaseMetadata {
+    tables: TableMetadata[];
+}
+/**
+ * Database introspector that queries database metadata
+ */
+export declare class DatabaseIntrospector {
+    protected db: Kysely<any>;
+    constructor(db: Kysely<any>);
+    /**
+     * Get all tables in the database
+     */
+    getTables(): Promise<TableMetadata[]>;
+    /**
+     * Get columns for a specific table
+     */
+    getColumns(tableName: string): Promise<ColumnMetadata[]>;
+    /**
+     * Get indexes for a specific table
+     */
+    getIndexes(tableName: string): Promise<IndexMetadata[]>;
+    /**
+     * Get foreign keys for a specific table
+     */
+    getForeignKeys(tableName: string): Promise<ForeignKeyMetadata[]>;
+}

package/dist/cjs/dialect/database-introspector.js

@@ -0,0 +1,85 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.DatabaseIntrospector = void 0;
+const sql_js_1 = require("../raw-builder/sql.js");
+/**
+ * Database introspector that queries database metadata
+ */
+class DatabaseIntrospector {
+    db;
+    constructor(db) {
+        this.db = db;
+    }
+    /**
+     * Get all tables in the database
+     */
+    async getTables() {
+        try {
+            // SQLite
+            const sqliteTables = await this.db
+                .selectFrom('sqlite_master')
+                .select('name')
+                .where('type', '=', 'table')
+                .where('name', 'not like', 'sqlite_%')
+                .execute();
+            return sqliteTables.map(t => ({
+                name: t.name
+            }));
+        }
+        catch (error) {
+            console.warn('SQLite table discovery failed:', error);
+            throw new Error('Unable to introspect database tables. SQLite database required.');
+        }
+    }
+    /**
+     * Get columns for a specific table
+     */
+    async getColumns(tableName) {
+        try {
+            // SQLite - use raw SQL for pragma_table_info
+            const result = await (0, sql_js_1.sql) `pragma_table_info(${sql_js_1.sql.lit(tableName)})`.execute(this.db);
+            const sqliteColumns = result.rows;
+            return sqliteColumns.map((col) => ({
+                name: col.name,
+                type: col.type,
+                nullable: !col.notnull,
+                defaultValue: col.dflt_value,
+                isPrimaryKey: !!col.pk,
+                isAutoIncrement: col.type.toLowerCase().includes('integer') && col.pk
+            }));
+        }
+        catch (error) {
+            console.warn('SQLite column discovery failed:', error);
+            throw new Error(`Unable to introspect columns for table '${tableName}'. SQLite database required.`);
+        }
+    }
+    /**
+     * Get indexes for a specific table
+     */
+    async getIndexes(tableName) {
+        // TODO: Implement index discovery for different databases
+        return [];
+    }
+    /**
+     * Get foreign keys for a specific table
+     */
+    async getForeignKeys(tableName) {
+        try {
+            // SQLite - use raw SQL for pragma_foreign_key_list
+            const result = await (0, sql_js_1.sql) `pragma_foreign_key_list(${sql_js_1.sql.lit(tableName)})`.execute(this.db);
+            const sqliteFks = result.rows;
+            return sqliteFks.map((fk) => ({
+                name: `fk_${tableName}_${fk.from}`,
+                column: fk.from,
+                referencedTable: fk.table,
+                referencedColumn: fk.to
+            }));
+        }
+        catch (error) {
+            console.warn('SQLite foreign key discovery failed:', error);
+            // Return empty array if foreign key discovery fails
+            return [];
+        }
+    }
+}
+exports.DatabaseIntrospector = DatabaseIntrospector;

package/dist/cjs/dialect/dialect-adapter-base.d.ts

@@ -0,0 +1,94 @@
+import { Kysely } from '../kysely.js';
+import { DialectAdapter, MigrationLockOptions } from './dialect-adapter.js';
+/**
+ * A basic implementation of `DialectAdapter` with sensible default values.
+ * Third-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.
+ */
+export declare abstract class DialectAdapterBase implements DialectAdapter {
+    /**
+     * 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.
+     */
+    get supportsCreateIfNotExists(): boolean;
+    /**
+     * Whether or not this dialect supports transactional DDL.
+     *
+     * If this is true, migrations are executed inside a transaction.
+     */
+    get supportsTransactionalDdl(): boolean;
+    /**
+     * Whether or not this dialect supports the `returning` in inserts
+     * updates and deletes.
+     */
+    get supportsReturning(): boolean;
+    get supportsOutput(): 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 {@link 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 {@link 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
+     * {@link 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:
+     *
+     * ```ts
+     * import { DialectAdapterBase, type MigrationLockOptions, Kysely } from 'kysely'
+     *
+     * export class MyAdapter extends DialectAdapterBase {
+     *   override async acquireMigrationLock(
+     *     db: Kysely<any>,
+     *     options: MigrationLockOptions
+     *   ): 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()
+     *   }
+     *
+     *   override async releaseMigrationLock() {
+     *     // noop
+     *   }
+     * }
+     * ```
+     *
+     * 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.
+     */
+    abstract acquireMigrationLock(db: Kysely<any>, options: MigrationLockOptions): Promise<void>;
+    /**
+     * Releases the migration lock. See {@link 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.
+     */
+    abstract releaseMigrationLock(db: Kysely<any>, options: MigrationLockOptions): Promise<void>;
+}

package/dist/cjs/dialect/dialect-adapter-base.js

@@ -0,0 +1,24 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.DialectAdapterBase = void 0;
+/**
+ * A basic implementation of `DialectAdapter` with sensible default values.
+ * Third-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.
+ */
+class DialectAdapterBase {
+    get supportsCreateIfNotExists() {
+        return true;
+    }
+    get supportsTransactionalDdl() {
+        return false;
+    }
+    get supportsReturning() {
+        return false;
+    }
+    get supportsOutput() {
+        return false;
+    }
+}
+exports.DialectAdapterBase = DialectAdapterBase;

package/dist/cjs/dialect/dialect-adapter.d.ts

@@ -0,0 +1,115 @@
+import { Kysely } from '../kysely.js';
+/**
+ * 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.
+ */
+export interface DialectAdapter {
+    /**
+     * 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 supportsCreateIfNotExists: boolean;
+    /**
+     * Whether or not this dialect supports transactional DDL.
+     *
+     * If this is true, migrations are executed inside a transaction.
+     */
+    readonly supportsTransactionalDdl: boolean;
+    /**
+     * Whether or not this dialect supports the `returning` in inserts
+     * updates and deletes.
+     */
+    readonly supportsReturning: boolean;
+    /**
+     * Whether or not this dialect supports the `output` clause in inserts
+     * updates and deletes.
+     */
+    readonly supportsOutput?: 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 {@link 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 {@link 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
+     * {@link 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:
+     *
+     * ```ts
+     * import { DialectAdapterBase, type MigrationLockOptions, Kysely } from 'kysely'
+     *
+     * export class MyAdapter extends DialectAdapterBase {
+     *   override async acquireMigrationLock(
+     *     db: Kysely<any>,
+     *     options: MigrationLockOptions
+     *   ): 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()
+     *   }
+     *
+     *   override async releaseMigrationLock() {
+     *     // noop
+     *   }
+     * }
+     * ```
+     *
+     * 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.
+     */
+    acquireMigrationLock(db: Kysely<any>, options: MigrationLockOptions): Promise<void>;
+    /**
+     * Releases the migration lock. See {@link 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.
+     */
+    releaseMigrationLock(db: Kysely<any>, options: MigrationLockOptions): Promise<void>;
+}
+export interface MigrationLockOptions {
+    /**
+     * The name of the migration lock table.
+     */
+    readonly lockTable: string;
+    /**
+     * The id of the only row in the migration lock table.
+     */
+    readonly lockRowId: string;
+    /**
+     * The schema in which the migration lock table lives. This is only
+     * defined if the user has specified a custom schema in the migration
+     * settings.
+     */
+    readonly lockTableSchema?: string;
+}

package/dist/cjs/dialect/dialect-adapter.js

@@ -0,0 +1,2 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });

package/dist/cjs/dialect/dialect.d.ts

@@ -0,0 +1,34 @@
+import { Driver } from '../driver/driver.js';
+import { Kysely } from '../kysely.js';
+import { QueryCompiler } from '../query-compiler/query-compiler.js';
+import { DatabaseIntrospector } from './database-introspector.js';
+import { DialectAdapter } from './dialect-adapter.js';
+/**
+ * A Dialect is the glue between Kysely and the underlying database engine.
+ *
+ * See the built-in {@link PostgresDialect} as an example of a dialect.
+ * Users can implement their own dialects and use them by passing it
+ * in the {@link KyselyConfig.dialect} property.
+ */
+export interface Dialect {
+    /**
+     * Creates a driver for the dialect.
+     */
+    createDriver(): Driver;
+    /**
+     * Creates a query compiler for the dialect.
+     */
+    createQueryCompiler(): QueryCompiler;
+    /**
+     * Creates an adapter for the dialect.
+     */
+    createAdapter(): DialectAdapter;
+    /**
+     * Creates a database introspector that can be used to get database metadata
+     * such as the table names and column names of those tables.
+     *
+     * `db` never has any plugins installed. It's created using
+     * {@link Kysely.withoutPlugins}.
+     */
+    createIntrospector(db: Kysely<any>): DatabaseIntrospector;
+}

package/dist/cjs/dialect/dialect.js

@@ -0,0 +1,2 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });

package/dist/cjs/dialect/sqlite/sqlite-adapter.d.ts

@@ -0,0 +1,80 @@
+import { Kysely } from '../../kysely.js';
+import { DialectAdapterBase } from '../dialect-adapter-base.js';
+import { MigrationLockOptions } from '../dialect-adapter.js';
+export declare class SqliteAdapter extends DialectAdapterBase {
+    /**
+     * Whether or not this dialect supports transactional DDL.
+     *
+     * If this is true, migrations are executed inside a transaction.
+     */
+    get supportsTransactionalDdl(): boolean;
+    /**
+     * Whether or not this dialect supports the `returning` in inserts
+     * updates and deletes.
+     */
+    get supportsReturning(): 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 {@link 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 {@link 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
+     * {@link 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:
+     *
+     * ```ts
+     * import { DialectAdapterBase, type MigrationLockOptions, Kysely } from 'kysely'
+     *
+     * export class MyAdapter extends DialectAdapterBase {
+     *   override async acquireMigrationLock(
+     *     db: Kysely<any>,
+     *     options: MigrationLockOptions
+     *   ): 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()
+     *   }
+     *
+     *   override async releaseMigrationLock() {
+     *     // noop
+     *   }
+     * }
+     * ```
+     *
+     * 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.
+     */
+    acquireMigrationLock(_db: Kysely<any>, _opt: MigrationLockOptions): Promise<void>;
+    /**
+     * Releases the migration lock. See {@link 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.
+     */
+    releaseMigrationLock(_db: Kysely<any>, _opt: MigrationLockOptions): Promise<void>;
+}