raggedstaff/openfoodnetwork
1
0
Fork 0
mirror of https://github.com/openfoodfoundation/openfoodnetwork synced 2026-01-31 21:37:16 +00:00
Code Issues Packages Projects Releases Wiki Activity

Updated Database migrations (markdown)

Maikel
2018-12-11 17:58:42 +11:00
parent 44b05c4d63
commit 83308290ae
1 changed files with 1 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
Database-migrations.md

@@ -7,4 +7,4 @@ https://blog.makandra.com/2010/03/how-to-use-models-in-your-migrations-without-k
### Always provide a rollback method
Simple migrations have a `change` method that can perform the migration and can be used to reverse it as well. But not everything can be reversed that easily. In that case you can declare the `up` and `down` methods, one for migrating and the other for rolling back. If the `up` method is destructive, you can't reverse it. For example, if you delete a whole column, the data is lost and can't be restored ... unless you keep a backup. No matter how simple the change is, we have some pretty complex production data and the simplest change can have nasty side effects. Therefore we should always write a backup file for the data we are destroying and provide a `down` method that can reverse the migration. The [first example](https://github.com/openfoodfoundation/openfoodnetwork/pull/3126/commits/f4d5727fb455618822f4bbd8415dea35d686434e) can give you an idea of how that works. Let's make it a bit more beautiful and re-usable next time we need a reversible destructive migration.
Simple migrations have a `change` method that can perform the migration and can be used to reverse it as well. But not everything can be reversed that easily. In that case you can declare the `up` and `down` methods, one for migrating and the other for rolling back. If the `up` method is destructive, you can't reverse it. For example, if you delete a whole column, the data is lost and can't be restored ... unless you keep a backup. No matter how simple the change is, we have some pretty complex production data and the simplest change can have nasty side effects. Therefore we should always write a backup file for the data we are destroying and provide a `down` method that can reverse the migration. The [first example](https://github.com/openfoodfoundation/openfoodnetwork/blob/master/db/migrate/20181123012635_associate_customers_to_users.rb) can give you an idea of how that works. Let's make it a bit more beautiful and re-usable next time we need a reversible destructive migration.