Bylaw.Credo.Check.Ecto.NoDataChangesInSchemaMigrations (bylaw_credo v0.3.1)

Basics

This check has a base priority of high and works with any version of Elixir.

Explanation

Keep Ecto migrations focused on database schema changes.

Examples

Avoid changing rows from a migration:

def up do
  Repo.update_all(Account, set: [status: :active])
  execute("DELETE FROM expired_sessions")
end

Prefer a reviewed data-migration script or explicit release task that can batch, throttle, observe, retry, and resume the work safely:

mix run priv/repo/data_migrations/backfill_account_statuses.exs

Why

Ecto migrations normally run while holding the migration lock and inside a DDL transaction. Row mutations and backfills can make that transaction unexpectedly long, block application traffic, and couple operational data work to schema deployment. Separate data migrations can be run at the right time with the operational safeguards their volume requires.

This check is a best-effort automated guideline, not an airtight boundary. It reports direct calls to common Repo mutation functions and literal SQL passed to any argument of execute/1,2 when its first statement, after leading whitespace and comments, begins with INSERT, UPDATE, DELETE, or MERGE. It intentionally does not guess about helper functions, dynamic SQL, or application-specific Repo wrappers.

If a data change genuinely belongs in a schema migration, disable the check locally with Credo and document why the exception is safe.

Options

This check has no check-specific options. Configure it with an empty option list.

Usage

Add this check to Credo's checks: list in .credo.exs:

%{
  configs: [
    %{
      name: "default",
      checks: [
        {Bylaw.Credo.Check.Ecto.NoDataChangesInSchemaMigrations, []}
      ]
    }
  ]
}

Check-Specific Parameters

There are no specific parameters for this check.

General Parameters

Like with all checks, general params can be applied.

Parameters can be configured via the .credo.exs config file.