Since Personalkollen runs on multiple servers/pods our users might experience some errors when dropping a field from production. This is because the migration is performed before the new pods have had time to deploy, so the production environment is technically running "old" code, that might be referencing the dropped field.
Here is what a a generated Django migration when dropping a field would look like.
# Generated by Django 5.0.9 on 2024-11-25 08:56
from django.db import migrations
class Migration(migrations.Migration):
dependencies = [
("staff", "0005_add_staff_field_that_will_be_dropped"),
]
operations = [
migrations.RemoveField(
model_name="staff",
name="field_that_will_be_dropped",
),
]
Deploying this to production will almost certainly cause some errors for our users.
In order to counteract this, we always separate these types of migrations into two migrations and, most importantly, apply the migrations on different deploys.
The first migration drops the field from Django.
# Generated by Personalkollen staff on 2024-11-25 08:57
from django.db import migrations, models
class Migration(migrations.Migration):
dependencies = [
("staff", "0005_add_staff_field_that_will_be_dropped"),
]
operations = [
migrations.SeparateDatabaseAndState(
state_operations=[
migrations.RemoveField(
model_name="staff",
name="field_that_will_be_dropped",
),
]
),
]
The second migration drops the field from the database.
# Generated by Personalkollen staff on 2024-11-25 08:58
from django.db import migrations
class Migration(migrations.Migration):
dependencies = [
("salary", "0006_remove_staff_field_that_will_be_dropped_from_django"),
]
operations = [
migrations.SeparateDatabaseAndState(
database_operations=[
migrations.RunSQL('ALTER TABLE "staff_staff" DROP COLUMN "field_that_will_be_dropped" CASCADE;')
]
),
]