Unique DB migration names

[fredwu]

Is your feature request related to a problem? Please describe.

At the moment, every time we run mix ash_postgres.generate_migrations, if there are changes, a migration file gets generated with names like 20220619142531_migrate_resources1.exs.

The problem with this is that when people work on different branches, they end up generating different migration files with the same module name, thus causing conflict.

Describe the solution you'd like

Instead of using 1, 2, 3... to increment the file and module names, a timestamp or UUID will prevent duplicated migration files far better.

So, instead of 20220619142531_migrate_resources1.exs, we could have either 20220619142531_migrate_ash_resources_20220619142531.exs or 20220619142531_migrate_ash_resources_863c8c09-a422-47e4-bb31-34a877825f85.exs.

What do you think?

[fredwu]

Turns out there is a larger issue. Due to the way resource snapshots are generated, merging two branches that touched the same resource is a bit of a challenge. :\ So even though we can simply change the migration files so there's no migration conflict, we'd still need to somehow manually update the snapshot files. ;(

[fredwu]

For keeping the snapshots up to date, I ended up running mix ash_postgres.generate_migrations to get the most up to date snapshots, and simply deleted the migration content from the newly generated migration file (as it contains migration steps that are duplicates due to the out of sync snapshots from the merging of branches).

[zachdaniel]

So this should help with the snapshots issue: #75.
Specifically, if there are multuple operations to add the same attribute, we won't need to reconcile them.

The main thing that you pretty much always need to do in either world is pull the latest and regenerate migrations before merging a branch.

Until that linked issue is resolved, what you'd want to do is pull, delete any generated snapshots and migrations, and regenerate them. Its not ideal, but the numbering naming convention causes a merge conflict, signaling that this needs to be done. Once we start using operations instead of snapshots, then I think we could switch to a convention of using timestamps for migrations.

With that said, you can also provide --migration-name to give each migration a specific name.

There isn't much to fix here, aside from addressing #75