- 22 May, 2017 1 commit
-
-
Lin Jen-Shin authored
-
- 15 May, 2017 1 commit
-
-
Douwe Maan authored
-
- 12 May, 2017 1 commit
-
-
Yorick Peterse authored
By adding the default value _after_ adding the column we avoid updating all rows in a table, saving a lot of time and unnecessary work in the process.
-
- 01 May, 2017 1 commit
-
-
Bob Van Landuyt authored
-
- 12 Apr, 2017 1 commit
-
-
Yorick Peterse authored
Starting with GitLab 9.1.0 we will no longer allow downtime migrations unless absolutely necessary. This commit updates the various developer guides and adds code that is necessary to make zero downtime migrations less painful.
-
- 11 Apr, 2017 1 commit
-
-
Tiago Botelho authored
-
- 05 Apr, 2017 1 commit
-
-
blackst0ne authored
-
- 23 Feb, 2017 2 commits
-
-
Douwe Maan authored
This reverts commit cb10b725c8929b8b4460f89c9d96c773af39ba6b.
-
Douwe Maan authored
-
- 21 Feb, 2017 1 commit
-
-
Yorick Peterse authored
This was initially not implemented simply because I forgot about the size limit of constraint names in PostgreSQL (63 bytes). Using the old technique we can't add foreign keys for certain tables. For example, adding a foreign key on protected_branch_merge_access_levels.protected_branch_id would lead to the following key name: fk_protected_branch_merge_access_levels_protected_branches_protected_branch_id This key is 78 bytes long, thus violating the PostgreSQL size requirements. The hashing strategy is copied from Rails' foreign_key_name() method, which unfortunately is private and subject to change without notice.
-
- 10 Feb, 2017 1 commit
-
-
Yorick Peterse authored
This method allows one to create foreign keys without blocking access to the source table, but only on PostgreSQL. When creating a regular foreign key the "ALTER TABLE" statement used for this won't return until all data has been validated. This statement in turn will acquire a lock on the source table. As a result this lock can be held for quite a long amount of time, depending on the number of rows and system load. By breaking up the foreign key creation process in two steps (creation, and validation) we can reduce the amount of locking to a minimum. Locking is still necessary for the "ALTER TABLE" statement that adds the constraint, but this is a fast process and so will only block access for a few milliseconds.
-
- 16 Sep, 2016 2 commits
-
-
Drew Blessing authored
-
Drew Blessing authored
-
- 15 Jul, 2016 1 commit
-
-
Stan Hu authored
-
- 16 Jun, 2016 2 commits
-
-
James Lopez authored
This reverts commit 13e37a3e.
-
James Lopez authored
-
- 15 Jun, 2016 2 commits
-
-
Yorick Peterse authored
This ensures that whatever locks are acquired aren't held onto until the end of the transaction (= after _all_ rows have been updated). Timing wise there's also no difference between using a transaction and not using one.
-
Yorick Peterse authored
By passing a block to update_column_in_batches() one can now customize the queries executed. This in turn can be used to only update a specific set of rows instead of simply all the rows in the table.
-
- 13 Jun, 2016 1 commit
-
-
Yorick Peterse authored
This ensures that whenever changing the NULL constraint of a column fails we still drop the column.
-
- 06 Jun, 2016 1 commit
-
-
Felipe Artur authored
-
- 03 Jun, 2016 2 commits
-
-
James Lopez authored
This reverts commit 3e991230.
-
James Lopez authored
# Conflicts: # app/models/project.rb
-
- 22 May, 2016 2 commits
-
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
- 12 May, 2016 2 commits
-
-
Yorick Peterse authored
-
Yorick Peterse authored
These helpers can be used to perform migrations without taking down the entire application. For example, the method "add_column_with_default" can be used to add a new column with a default value without locking the entire table.
-