Specs

run(Ecto.Repo.t(), atom(), Keyword.t()) :: [integer()]

Runs migrations for the given repository.

Equivalent to:

Ecto.Migrator.run(repo, [Ecto.Migrator.migrations_path(repo)], direction, opts)

See run/4 for more information.

Specs

run(
  Ecto.Repo.t(),
  String.t() | [String.t()] | [{integer(), module()}],
  atom(),
  Keyword.t()
) :: [integer()]

Apply migrations to a repository with a given strategy.

The second argument identifies where the migrations are sourced from. A binary representing directory (or a list of binaries representing directories) may be passed, in which case we will load all files following the "#{VERSION}_#{NAME}.exs" schema. The migration_source may also be a list of tuples that identify the version number and migration modules to be run, for example:

Ecto.Migrator.run(Repo, [{0, MyApp.Migration1}, {1, MyApp.Migration2}, ...], :up, opts)

A strategy (which is one of :all, :step or :to) must be given as an option.

Execution model

In order to run migrations, at least two database connections are necessary. One is used to lock the "schema_migrations" table and the other one to effectively run the migrations. This allows multiple nodes to run migrations at the same time, but guarantee that only one of them will effectively migrate the database.

A downside of this approach is that migrations cannot run dynamically during test under the Ecto.Adapters.SQL.Sandbox, as the sandbox has to share a single connection across processes to guarantee the changes can be reverted.

Options

• :all - runs all available if true
• :step - runs the specific number of migrations
• :to - runs all until the supplied version is reached
• :log - the level to use for logging. Defaults to :info. Can be any of Logger.level/0 values or a boolean.
• :prefix - the prefix to run the migrations on
• :dynamic_repo - the name of the Repo supervisor process. See Ecto.Repo.put_dynamic_repo/1.