# Migrations

## Tasks

The available tasks are:

* `mix ash_postgres.generate_migrations`
* `mix ash_postgres.create`
* `mix ash_postgres.drop`
* `mix ash_postgres.migrate` (use `mix ash_postgres.migrate --tenants` to run tenant migrations)

AshPostgres is built on top of ecto, so much of its behavior is pass-through/orchestration of that tooling.

## Basic Workflow

* Make resource changes
* Run `mix ash_postgres.generate_migrations` to generate migrations and resource snapshots
* Run `mix ash_postgres.migrate` to run those migrations
* Run `mix ash_postgres.migrate --tenants` *as well* if you have multi-tenant resources.


For more information on generating migrations, see the module documentation here:
`Mix.Tasks.AshPostgres.GenerateMigrations`, or run `mix help ash_postgres.generate_migrations`

For running your migrations, there is a mix task that will find all of the repos configured in your apis and run their
migrations. It is a thin wrapper around `mix ecto.migrate`. Ours is called `mix ash_postgres.migrate`

If you want to run or rollback individual migrations, use the corresponding 

For tenant migrations (see the multitenancy guides for more) generated by multitenant resources, make sure you are using
`mix ash_postgres.generate_migrations`. It is not sufficient to run `mix ash_postgres.migrate --migrations_path tenant_migrations_path`. You will also need to define a `list_tenants/0` function in your repo module. See `AshPostgres.Repo` for more.

## Multiple Repos

If you are using multiple repos, you will likely need to use `mix ecto.migrate` and manage it separately for each repo, as the options would
be applied to both repo, which wouldn't make sense.