Struct InitializationHandler 

pub struct InitializationHandler { /* private fields */ }

Batch DDL migration executor with tracking.

Maintains a _dbkit_migrations table so already-applied migrations are skipped on subsequent runs. Each migration is identified by a user-provided name and a content hash.

The tracking table DDL and the internal queries are backend-aware (Postgres / MySQL / SQLite), so the migration runner works on any backend. The user-supplied migration SQL is still backend-native — write it for the database you connected to.

Implementations

impl InitializationHandler

pub fn new(pool: AnyPool, backend: Backend) -> Self

Create a handler for the given pool and backend.

The backend is typically obtained from ConnectionManager::backend.

pub async fn run_named_migration( &self, name: &str, sql: &str, ) -> Result<(), DbkitError>

Run a named migration. Skips if already applied with the same content hash.

If the migration name exists but the hash differs, it returns an error (content changed after being applied).

pub async fn run_migrations(&self, sql: &str) -> Result<(), DbkitError>

Run migrations from a SQL string (semicolon-separated DDL statements).

Statements are split on ;, so this does not support SQL that embeds semicolons inside a single statement (string literals, PL/pgSQL function bodies, triggers). Run such migrations as a single statement through WriteOp::BatchDDL directly.

This is the simple/legacy API — it runs all statements unconditionally without tracking. Use run_named_migration for tracked migrations.

pub async fn applied_migrations( &self, ) -> Result<Vec<(String, String, String)>, DbkitError>

List all applied migrations (name, hash, applied_at) in application order.