From 7eca3f56625526ffa7f263c1fef0fcea34de8ca6 Mon Sep 17 00:00:00 2001 From: GitLab Bot Date: Fri, 13 May 2022 15:07:43 +0000 Subject: Add latest changes from gitlab-org/gitlab@master --- doc/development/adding_database_indexes.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) (limited to 'doc/development/adding_database_indexes.md') diff --git a/doc/development/adding_database_indexes.md b/doc/development/adding_database_indexes.md index d263d9b5eb5..35dbd80e4d1 100644 --- a/doc/development/adding_database_indexes.md +++ b/doc/development/adding_database_indexes.md @@ -158,7 +158,7 @@ and should not be used. Some other points to consider: ### Why explicit names are required As Rails is database agnostic, it generates an index name only -from the required options of all indexes: table name and column name(s). +from the required options of all indexes: table name and column names. For example, imagine the following two indexes are created in a migration: ```ruby @@ -173,7 +173,7 @@ Creation of the second index would fail, because Rails would generate the same name for both indexes. This is further complicated by the behavior of the `index_exists?` method. -It considers only the table name, column name(s) and uniqueness specification +It considers only the table name, column names, and uniqueness specification of the index when making a comparison. Consider: ```ruby @@ -284,8 +284,9 @@ production clone. ### Add a migration to create the index synchronously After the index is verified to exist on the production database, create a second -merge request that adds the index synchronously. The synchronous -migration results in a no-op on GitLab.com, but you should still add the +merge request that adds the index synchronously. The schema changes must be +updated and committed to `structure.sql` in this second merge request. +The synchronous migration results in a no-op on GitLab.com, but you should still add the migration as expected for other installations. The below block demonstrates how to create the second migration for the previous asynchronous example. -- cgit v1.2.1