From ee664acb356f8123f4f6b00b73c1e1cf0866c7fb Mon Sep 17 00:00:00 2001 From: GitLab Bot Date: Thu, 20 Oct 2022 09:40:42 +0000 Subject: Add latest changes from gitlab-org/gitlab@15-5-stable-ee --- doc/development/database/background_migrations.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'doc/development/database/background_migrations.md') diff --git a/doc/development/database/background_migrations.md b/doc/development/database/background_migrations.md index 9b596eb7379..8e6f29b9eb8 100644 --- a/doc/development/database/background_migrations.md +++ b/doc/development/database/background_migrations.md @@ -1,7 +1,7 @@ --- stage: Data Stores group: Database -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 +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments --- # Background migrations @@ -44,7 +44,7 @@ into this category. ## Isolation -Background migrations must be isolated and can not use application code (for example, +Background migrations must be isolated and cannot use application code (for example, models defined in `app/models` except the `ApplicationRecord` classes). Since these migrations can take a long time to run it's possible for new versions to be deployed while they are still running. @@ -86,7 +86,7 @@ migration classes must be defined in the namespace Scheduling a background migration should be done in a post-deployment migration that includes `Gitlab::Database::MigrationHelpers` -To do so, simply use the following code while +To do so, use the following code while replacing the class name and arguments with whatever values are necessary for your migration: @@ -110,7 +110,7 @@ You also need to make sure that newly created data is either migrated, or saved in both the old and new version upon creation. For complex and time consuming migrations it's best to schedule a background job using an `after_create` hook so this doesn't affect response timings. The same applies to -updates. Removals in turn can be handled by simply defining foreign keys with +updates. Removals in turn can be handled by defining foreign keys with cascading deletes. ### Rescheduling background migrations -- cgit v1.2.3