Does Knex.js provide a mechanism to handle partial DDL failures in non-transactional dialects?

Migration State and DDL Rollbacks

Knex.js manages migration state via a migrations table and a lock mechanism to prevent concurrent execution. For dialects supporting transactional DDL, such as PostgreSQL, Knex wraps migrations in transactions to ensure atomicity. However, MySQL and MariaDB do not support rolling back DDL statements.

Consistency Constraints

When a migration fails on a non-transactional dialect, the migration is not recorded as applied in the database. Despite this, any DDL statements executed prior to the failure remain committed to the schema. This creates a discrepancy between the actual database state and the migration history recorded by Knex.

Because knex migrate:rollback relies on the down method of the last successful batch, it may not target the partial changes left by a failed migration attempt.

• Which strategy is recommended to detect and resolve partial schema changes before re-running a failed migration?
• Does Knex provide a built-in way to force a transactional wrap on dialects that do not natively support it, or must this be handled via manual idempotency in the migration scripts?