Skip to content

fix(docs): clarify database migrations #13026

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
JoshFerge merged 4 commits into from
Mar 31, 2025
Merged

fix(docs): clarify database migrations #13026

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
240a99d
fix(docs): clarify database migrations
JoshFerge Mar 17, 2025
8e2fb4d
Update develop-docs/backend/application-domains/database-migrations/i…
JoshFerge Mar 18, 2025
6900d03
delete line 140
JoshFerge Mar 31, 2025
479d94a
Update develop-docs/backend/application-domains/database-migrations/i…
JoshFerge Mar 31, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions develop-docs/backend/application-domains/database-migrations/index.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -134,9 +134,9 @@ 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, then make a PR to make it nullable via `null=True`.
- 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:
- 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
Expand Down