ash_postgres v0.30.1 mix ash_postgres.generate_migrations View Source
Generates migrations, and stores a snapshot of your resources.
apis- a comma separated list of API modules, for which migrations will be generated
snapshot_path- a custom path to store the snapshots, defaults to "priv/resource_snapshots"
migration_path- a custom path to store the migrations, defaults to "priv". Migrations are stored in a folder for each repo, so
tenant_migration_path- Same as
migration_path, except for any tenant specific migrations
drop_columns- whether or not to drop columns as attributes are removed. See below for more
quiet- messages for file creations will not be printed
no_format- files that are created will not be formatted with the code formatter
dry_run- no files are created, instead the new migration is printed
check_migrated- no files are created, returns an exit(1) code if the current snapshots and resources don't fit
Snapshots are stored in a folder for each table that migrations are generated for. Each snapshot is stored in a file with a timestamp of when it was generated. This is important because it allows for simultaneous work to be done on separate branches, and for rolling back changes more easily, e.g removing a generated migration, and deleting the most recent snapshot, without having to redo all of it
Generally speaking, it is bad practice to drop columns when you deploy a change that
would remove an attribute. The main reasons for this are backwards compatibility and rolling restarts.
If you deploy an attribute removal, and run migrations. Regardless of your deployment sstrategy, you
won't be able to roll back, because the data has been deleted. In a rolling restart situation, some of
the machines/pods/whatever may still be running after the column has been deleted, causing errors. With
this in mind, its best not to delete those columns until later, after the data has been confirmed unnecessary.
To that end, the migration generator leaves the column dropping code commented. You can pass
to tell it to uncomment those statements. Additionally, you can just uncomment that code on a case by case
The migration generator can support multiple schemas using the same table. It will raise on conflicts that it can't resolve, like the same field with different types. It will prompt to resolve conflicts that can be resolved with human input. For example, if you remove an attribute and add an attribute, it will ask you if you are renaming the column in question. If not, it will remove one column and add the other.
Additionally, it lowers things to the database where possible:
There are three anonymous functions that will translate to database-specific defaults currently:
&Ash.uuid/0- Only if
uuid-osspis in your
&Ecto.UUID.generate/0- Only if
uuid-osspis in your
Non-function default values will be dumped to their native type and inspected. This may not work for some types, and may require manual intervention/patches to the migration generator code.
Identities will cause the migration generator to generate unique constraints. If multiple resources target the same table, you will be asked to select the primary key, and any others will be added as unique constraints.