From 240a99dcf63174a2474a1aa18b5d9123d884b28e Mon Sep 17 00:00:00 2001 From: Joshua Ferge Date: Mon, 17 Mar 2025 19:41:02 -0400 Subject: [PATCH 1/4] fix(docs): clarify database migrations --- .../backend/application-domains/database-migrations/index.mdx | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/develop-docs/backend/application-domains/database-migrations/index.mdx b/develop-docs/backend/application-domains/database-migrations/index.mdx index 2c43cda3ee18fc..8aa4e1a3f45875 100644 --- a/develop-docs/backend/application-domains/database-migrations/index.mdx +++ b/develop-docs/backend/application-domains/database-migrations/index.mdx @@ -134,7 +134,8 @@ This is complicated due to our deploy process. When we deploy, we run migrations To avoid this, follow these steps: -- Make a PR to remove all uses of the column in the codebase in a separate PR. This mostly helps with code cleanliness. This should be merged ahead of the migration prs, but we don't need to worry about whether it is deployed first. +- First, if the column is either not nullable, or doesn't have a `db_default` set. If either of these is true, then make it nullable via `null=True`. +- Then, make a PR to remove all uses of the column in the codebase in a separate PR. This mostly helps with code cleanliness. This should be merged ahead of the next migration PRs, but we don't need to worry about whether it is deployed first. - Make another PR that: - Checks if the column is either not nullable, or doesn't have a `db_default` set. If either of these is true, then make it nullable via `null=True`. - If the column is a foreign key, remove the database level foreign key constraint it by setting `db_constraint=False`. From 8e2fb4dec66d041bd9ed41d2d1a068e8b4316c69 Mon Sep 17 00:00:00 2001 From: Josh Ferge Date: Tue, 18 Mar 2025 10:38:26 -0400 Subject: [PATCH 2/4] Update develop-docs/backend/application-domains/database-migrations/index.mdx Co-authored-by: Michael Sun <55160142+MichaelSun48@users.noreply.github.com> --- .../backend/application-domains/database-migrations/index.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/develop-docs/backend/application-domains/database-migrations/index.mdx b/develop-docs/backend/application-domains/database-migrations/index.mdx index 8aa4e1a3f45875..7948afed4747d3 100644 --- a/develop-docs/backend/application-domains/database-migrations/index.mdx +++ b/develop-docs/backend/application-domains/database-migrations/index.mdx @@ -134,7 +134,7 @@ This is complicated due to our deploy process. When we deploy, we run migrations To avoid this, follow these steps: -- First, if the column is either not nullable, or doesn't have a `db_default` set. If either of these is true, then make it nullable via `null=True`. +- First, if the column is either not nullable, or doesn't have a `db_default` set, then make a PR to make it nullable via `null=True`. - Then, make a PR to remove all uses of the column in the codebase in a separate PR. This mostly helps with code cleanliness. This should be merged ahead of the next migration PRs, but we don't need to worry about whether it is deployed first. - Make another PR that: - Checks if the column is either not nullable, or doesn't have a `db_default` set. If either of these is true, then make it nullable via `null=True`. From 6900d03ca72fe2b2dfbc75a73af0cbc25855adb5 Mon Sep 17 00:00:00 2001 From: Joshua Ferge Date: Mon, 31 Mar 2025 10:58:45 -0400 Subject: [PATCH 3/4] delete line 140 --- .../backend/application-domains/database-migrations/index.mdx | 1 - 1 file changed, 1 deletion(-) diff --git a/develop-docs/backend/application-domains/database-migrations/index.mdx b/develop-docs/backend/application-domains/database-migrations/index.mdx index 7948afed4747d3..3688e9e43072cf 100644 --- a/develop-docs/backend/application-domains/database-migrations/index.mdx +++ b/develop-docs/backend/application-domains/database-migrations/index.mdx @@ -137,7 +137,6 @@ To avoid this, follow these steps: - First, if the column is either not nullable, or doesn't have a `db_default` set, then make a PR to make it nullable via `null=True`. - Then, make a PR to remove all uses of the column in the codebase in a separate PR. This mostly helps with code cleanliness. This should be merged ahead of the next migration PRs, but we don't need to worry about whether it is deployed first. - Make another PR that: - - Checks if the column is either not nullable, or doesn't have a `db_default` set. If either of these is true, then make it nullable via `null=True`. - If the column is a foreign key, remove the database level foreign key constraint it by setting `db_constraint=False`. - Remove the column and in the generated migration use `SafeRemoveField(..., deletion_action=DeletionAction.MOVE_TO_PENDING)` to replace `RemoveField(...)`. This only marks the state for the column as removed. - Combine these migrations together to save making multiple deploys From 479d94a87b7ff6183163df09764fe0e308ff1283 Mon Sep 17 00:00:00 2001 From: Josh Ferge Date: Mon, 31 Mar 2025 11:00:01 -0400 Subject: [PATCH 4/4] Update develop-docs/backend/application-domains/database-migrations/index.mdx Co-authored-by: Alex Krawiec --- .../backend/application-domains/database-migrations/index.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/develop-docs/backend/application-domains/database-migrations/index.mdx b/develop-docs/backend/application-domains/database-migrations/index.mdx index 3688e9e43072cf..1ffa04e3399a67 100644 --- a/develop-docs/backend/application-domains/database-migrations/index.mdx +++ b/develop-docs/backend/application-domains/database-migrations/index.mdx @@ -135,7 +135,7 @@ This is complicated due to our deploy process. When we deploy, we run migrations To avoid this, follow these steps: - First, if the column is either not nullable, or doesn't have a `db_default` set, then make a PR to make it nullable via `null=True`. -- Then, make a PR to remove all uses of the column in the codebase in a separate PR. This mostly helps with code cleanliness. This should be merged ahead of the next migration PRs, but we don't need to worry about whether it is deployed first. +- Then, remove all uses of the column in the codebase in a separate PR; this mostly helps with code cleanliness. This should be merged ahead of the next migration PRs, but we don't need to worry about whether it is deployed first. - Make another PR that: - If the column is a foreign key, remove the database level foreign key constraint it by setting `db_constraint=False`. - Remove the column and in the generated migration use `SafeRemoveField(..., deletion_action=DeletionAction.MOVE_TO_PENDING)` to replace `RemoveField(...)`. This only marks the state for the column as removed.