diff options
| author | GitLab Bot <gitlab-bot@gitlab.com> | 2022-10-20 12:40:42 +0300 |
|---|---|---|
| committer | GitLab Bot <gitlab-bot@gitlab.com> | 2022-10-20 12:40:42 +0300 |
| commit | ee664acb356f8123f4f6b00b73c1e1cf0866c7fb (patch) | |
| tree | f8479f94a28f66654c6a4f6fb99bad6b4e86a40e /doc/development/database/background_migrations.md | |
| parent | 62f7d5c5b69180e82ae8196b7b429eeffc8e7b4f (diff) | |
Add latest changes from gitlab-org/gitlab@15-5-stable-eev15.5.0-rc42
Diffstat (limited to 'doc/development/database/background_migrations.md')
| -rw-r--r-- | doc/development/database/background_migrations.md | 8 |
1 files changed, 4 insertions, 4 deletions
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 |