diff options
| author | GitLab Bot <gitlab-bot@gitlab.com> | 2022-06-07 18:09:27 +0000 |
|---|---|---|
| committer | GitLab Bot <gitlab-bot@gitlab.com> | 2022-06-07 18:09:27 +0000 |
| commit | 5cda8c8a420399ca9687c4a981fefd50ce5a1fdd (patch) | |
| tree | 6050d7517a36798c9586e153df20a0696c5fcd4f /doc/development/swapping_tables.md | |
| parent | 7bbc731c75d0b8bf7c74ba77d521266d2ed0a1fc (diff) | |
| download | gitlab-ce-5cda8c8a420399ca9687c4a981fefd50ce5a1fdd.tar.gz | |
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc/development/swapping_tables.md')
| -rw-r--r-- | doc/development/swapping_tables.md | 12 |
1 files changed, 6 insertions, 6 deletions
diff --git a/doc/development/swapping_tables.md b/doc/development/swapping_tables.md index d6c5b8f0662..efb481ccf35 100644 --- a/doc/development/swapping_tables.md +++ b/doc/development/swapping_tables.md @@ -10,12 +10,12 @@ Sometimes you need to replace one table with another. For example, when migrating data in a very large table it's often better to create a copy of the table and insert & migrate the data into this new table in the background. -Let's say you want to swap the table "events" with "events_for_migration". In +Let's say you want to swap the table `events` with `events_for_migration`. In this case you need to follow 3 steps: -1. Rename "events" to "events_temporary" -1. Rename "events_for_migration" to "events" -1. Rename "events_temporary" to "events_for_migration" +1. Rename `events` to `events_temporary` +1. Rename `events_for_migration` to `events` +1. Rename `events_temporary` to `events_for_migration` Rails allows you to do this using the `rename_table` method: @@ -27,7 +27,7 @@ rename_table :events_temporary, :events_for_migration This does not require any downtime as long as the 3 `rename_table` calls are executed in the _same_ database transaction. Rails by default uses database -transactions for migrations, but if it doesn't you'll need to start one +transactions for migrations, but if it doesn't you need to start one manually: ```ruby @@ -45,7 +45,7 @@ PostgreSQL you can use the `reset_pk_sequence!` method like so: reset_pk_sequence!('events') ``` -Failure to reset the primary keys will result in newly created rows starting +Failure to reset the primary keys results in newly created rows starting with an ID value of 1. Depending on the existing data this can then lead to duplicate key constraints from popping up, preventing users from creating new data. |
