How do you edit migrations in regards to the generated snapshots?
With plain Ecto you can do whatever you want with old migrations as long as theyre not yet deployed, or if you don't mind wiping the database. I think this changes in regards to the snapshots that Ash generates in addition to generating the migrations.
What is the recommended way of editing old migrations and keeping the generated snapshots in sync with these edited migrations?
Solution:Jump to solution
You're free to edit the migration files yourself, they're generated for your convenience but it's always wise to look over them to ensure you got what you expected, as long as you also update the snapshots accordingly so that they are in sync 😄
This can be a bit tedious however, so I at least prefer to just remove the "incorrect" migrations/snapshots, and start over from the last deployed versions.
One approach for getting "updated versions" if you have made some changes after generating migrations, is to delete both the migration file in question, and all the resource snapshots that was also generated when running
ash.migrate. Then the previous deployed snapshot will be used as a base for diffing what has changed, and you will get an up to date migration with all the changes...4 Replies
Solution
You're free to edit the migration files yourself, they're generated for your convenience but it's always wise to look over them to ensure you got what you expected, as long as you also update the snapshots accordingly so that they are in sync 😄
This can be a bit tedious however, so I at least prefer to just remove the "incorrect" migrations/snapshots, and start over from the last deployed versions.
One approach for getting "updated versions" if you have made some changes after generating migrations, is to delete both the migration file in question, and all the resource snapshots that was also generated when running
ash.migrate. Then the previous deployed snapshot will be used as a base for diffing what has changed, and you will get an up to date migration with all the changesIf you're iterating over some changes in the data model, using
mix ash.codegen --dev is very convenient, then you will create "dev" snapshots and migrations, and once you're happy with the state of things and want to solidify them, you run mix ash.migrate my_new_migration, which will basically remove all the *.dev.exs & *.dev.json migrations and snapshots, and regenerate new ones with all the changes included
Basically ash.codegen --dev automates the process I described first there 😎the problem is that even after solidifying the dev changes, I might still change my mind 😅
how do I know which snapshots to remove? do the timestamps match the ones from the migrations?
They are created with a timestamp, so you would have to know which one is the last one that was deployed based on that
And they match the timestamps used on the migrations 😄