I’m confused about the reasoning for the DB Migrations.
I understand how they work, you create a MigrationXXXX class, in which you add the changes only, and the “AppTask” will add/remove/rename columns.
But, previously we have always used CreateTableIfNotExists
functions, and that works great when putting the code on a new server.
However, I’m thinking that this won’t work anymore. As the “main class”, which represents a table, is always the most updated one. If I were to put my code on a new server, run CreateTable
, that would create the most up-to-date definition of the table. But the migrations are of course based on some historical version of the table, and the changes thereafter.
So in practice, this means:
- I’ll have to backtrack each migration and try to reconstruct the class/table before the 1st migration.
- Then that “original table class” will be put in the very first migration, using
CreatTable
in there. - I’ll have to maintain two “copies” of my table-classes from now on. One in the migrations, and one up-to-date one, that I’ll use everywhere in my code.
Is this how it’s supposed to work?