debian-mirror-gitlab/doc/development/swapping_tables.md

52 lines
1.7 KiB
Markdown
Raw Normal View History

2021-01-03 14:25:43 +05:30
---
2022-07-23 23:45:48 +05:30
stage: Data Stores
2021-01-03 14:25:43 +05:30
group: Database
2021-02-22 17:27:13 +05:30
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
2021-01-03 14:25:43 +05:30
---
2018-03-17 18:26:18 +05:30
# Swapping Tables
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.
2022-07-23 23:45:48 +05:30
Let's say you want to swap the table `events` with `events_for_migration`. In
2018-03-17 18:26:18 +05:30
this case you need to follow 3 steps:
2022-07-23 23:45:48 +05:30
1. Rename `events` to `events_temporary`
1. Rename `events_for_migration` to `events`
1. Rename `events_temporary` to `events_for_migration`
2018-03-17 18:26:18 +05:30
Rails allows you to do this using the `rename_table` method:
```ruby
rename_table :events, :events_temporary
rename_table :events_for_migration, :events
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
2022-07-23 23:45:48 +05:30
transactions for migrations, but if it doesn't you need to start one
2018-03-17 18:26:18 +05:30
manually:
```ruby
Event.transaction do
rename_table :events, :events_temporary
rename_table :events_for_migration, :events
rename_table :events_temporary, :events_for_migration
end
```
Once swapped you _have to_ reset the primary key of the new table. For
PostgreSQL you can use the `reset_pk_sequence!` method like so:
```ruby
reset_pk_sequence!('events')
```
2022-07-23 23:45:48 +05:30
Failure to reset the primary keys results in newly created rows starting
2018-03-17 18:26:18 +05:30
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.