You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For bulk data loads you can't know the migration will have time to complete in CI. So it could be nice to break up data updates by date ranges or pages. But if it fails or doesn't finish the complete change, you wouldn't want to restart the entire paging process again.
So it would be nice to be able to define an atomic migration programmatically. So you could generate migrations in file and then you've got a kind of checkpoint for the data load.
for(letdateofdaterange){pgmg.migrate('big data load '+date,{asyncaction(sql){awaitsql`update ... where date is between ${date} and ${...}`
}})}
If you have that API, you need to run the file to discover what migrations exist. And the number of migrations could be dynamic. E.g. the name there could change if the data in prod shifts dates, which means a prior migration that we considered "done" may suddenly re-run and crash.
Should we instead still have a concept of a migration being done, but introduce an idea of snapshots within a migration hook. So if the hook restarts on a second attempt, the snapshots can resume, but if the hook is marked as complete, we don't enter it to eval the snapshots to run.
The text was updated successfully, but these errors were encountered:
For bulk data loads you can't know the migration will have time to complete in CI. So it could be nice to break up data updates by date ranges or pages. But if it fails or doesn't finish the complete change, you wouldn't want to restart the entire paging process again.
So it would be nice to be able to define an atomic migration programmatically. So you could generate migrations in file and then you've got a kind of checkpoint for the data load.
If you have that API, you need to run the file to discover what migrations exist. And the number of migrations could be dynamic. E.g. the name there could change if the data in prod shifts dates, which means a prior migration that we considered "done" may suddenly re-run and crash.
Should we instead still have a concept of a migration being done, but introduce an idea of snapshots within a migration hook. So if the hook restarts on a second attempt, the snapshots can resume, but if the hook is marked as complete, we don't enter it to eval the snapshots to run.
The text was updated successfully, but these errors were encountered: