Data Update Migrations
🟢SQL
I've got a branch where I want to consolidate many cron jobs into one. To do that I need to:
1. create a new table,
2. pull data from the existing cron jobs into that new table,
3. create one new cron job, and
4. delete all the old cron jobs.
I'm building this in my local environmnent, but I'm not sure the best way to move the data around. Should I do this with a migration, which will run on Prod automatically, or should I just include the table build in the migration and run the data movement script manually against the database?
The documentation suggests I should only make schema changes in migrations.
In my case I could mange that by just choosing a time in-between cron runs.
But I'm curious about modifications to an active production database where the tables in question are in constant active use and where limiting downtime is essential. A data movement migration script seems very useful in that context, since it would run as soon as the objects have been modified.
Is there a better way?
1. create a new table,
2. pull data from the existing cron jobs into that new table,
3. create one new cron job, and
4. delete all the old cron jobs.
I'm building this in my local environmnent, but I'm not sure the best way to move the data around. Should I do this with a migration, which will run on Prod automatically, or should I just include the table build in the migration and run the data movement script manually against the database?
The documentation suggests I should only make schema changes in migrations.
In my case I could mange that by just choosing a time in-between cron runs.
But I'm curious about modifications to an active production database where the tables in question are in constant active use and where limiting downtime is essential. A data movement migration script seems very useful in that context, since it would run as soon as the objects have been modified.
Is there a better way?
