CtrlK
BlogDocsLog inGet started
Tessl Logo

vishnu/database-migration-helper

Creates and manages database migrations, including generating migration files, writing up/down migration logic, running schema changes, resolving migration conflicts, and testing rollbacks. Use when asked to add a column, rename a table, ALTER TABLE, create a migration file, run db migrate, handle schema changes, or work with migration tools like Alembic, Knex, Rails ActiveRecord, Flyway, or Liquibase.

72

Quality

90%

Does it follow best practices?

Impact

—

No eval scenarios have been run

SecuritybySnyk

Passed

No known issues

Overview
Quality
Evals
Security
Files
name:
database-migration-helper
description:
Creates and manages database migrations, including generating migration files, writing up/down migration logic, running schema changes, resolving migration conflicts, and testing rollbacks. Use when asked to add a column, rename a table, ALTER TABLE, create a migration file, run db migrate, handle schema changes, or work with migration tools like Alembic, Knex, Rails ActiveRecord, Flyway, or Liquibase.

Database Migration Helper

Workflow

Follow these steps when creating or running a migration:

  1. Generate the migration file using your framework's CLI (examples below)
  2. Write the up migration
  3. Write the down migration
  4. Wrap in a transaction where supported to ensure atomicity
  5. Run the migration against a local or staging database first
  6. Validate schema — inspect the resulting table/column structure
  7. Test the rollback — run the down migration and confirm the schema reverts cleanly

Framework Examples

Knex (JavaScript)

// migrations/20240101_add_email_to_users.js
exports.up = function (knex) {
  return knex.schema.table('users', (table) => {
    table.string('email').notNullable().defaultTo('');
  });
};

exports.down = function (knex) {
  return knex.schema.table('users', (table) => {
    table.dropColumn('email');
  });
};

Commands:

knex migrate:make add_email_to_users   # generate file
knex migrate:latest                    # run up
knex migrate:rollback                  # run down
knex migrate:status                    # check applied migrations

Alembic (Python / SQLAlchemy)

# alembic/versions/abc123_add_email_to_users.py
def upgrade():
    with op.batch_alter_table('users') as batch_op:
        batch_op.add_column(sa.Column('email', sa.String(255), nullable=False, server_default=''))

def downgrade():
    with op.batch_alter_table('users') as batch_op:
        batch_op.drop_column('email')

Commands:

alembic revision --autogenerate -m "add_email_to_users"  # generate
alembic upgrade head                                      # run up
alembic downgrade -1                                      # run down
alembic current                                           # check state

Rails ActiveRecord

# db/migrate/20240101000000_add_email_to_users.rb
class AddEmailToUsers < ActiveRecord::Migration[7.1]
  def up
    add_column :users, :email, :string, null: false, default: ''
  end

  def down
    remove_column :users, :email
  end
end

Commands:

rails generate migration AddEmailToUsers email:string   # generate
rails db:migrate                                        # run up
rails db:rollback                                       # run down
rails db:migrate:status                                 # check state

Key Rules

  • Never modify an already-applied migration — create a new one instead
  • Always pair up with a reversible down — if a step is irreversible (e.g., dropping a column with data), document it explicitly
  • Use transactions wherever the database supports transactional DDL (PostgreSQL yes, MySQL/MariaDB limited)
  • Keep each migration focused on a single logical schema change to simplify conflict resolution and rollback
Workspace
vishnu
Visibility
Public
Created
Last updated
Publish Source
CLI
Badge
vishnu/database-migration-helper badge