ash_postgres/documentation/migrations_and_tasks.md
2021-01-26 19:24:25 -05:00

36 lines
1.7 KiB
Markdown

# 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.