-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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.
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
Use django-safemigrate for migrations #11087
Changes from all commits
f321968
e31f17d
477da9d
7a89724
369065f
34c9e4b
43b27bf
8110925
9e4f28e
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
+25 −0 | dockerfiles/docker-compose.yml | |
+3 −0 | dockerfiles/entrypoints/common.sh | |
+2 −8 | isort.cfg | |
+22 −12 | pre-commit-config.yaml |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,133 @@ | ||
Database migrations | ||
=================== | ||
|
||
We use `Django migrations <https://docs.djangoproject.com/en/4.2/topics/migrations/>`__ to manage database schema changes, | ||
and the `django-safemigrate <https://github.com/aspiredu/django-safemigrate>`__ package to ensure that migrations are run in a given order to avoid downtime. | ||
|
||
To make sure that migrations don't cause downtime, | ||
the following rules should be followed for each case. | ||
|
||
Adding a new field | ||
------------------ | ||
|
||
**When adding a new field to a model, it should be nullable.** | ||
This way, the database can be migrated without downtime, and the field can be populated later. | ||
Don't forget to make the field non-nullable in a separate migration after the data has been populated. | ||
You can achieve this by following these steps: | ||
|
||
- #. Set the new field as ``null=True`` and ``blank=True`` in the model. | ||
|
||
.. code-block:: python | ||
|
||
class MyModel(models.Model): | ||
new_field = models.CharField( | ||
max_length=100, null=True, blank=True, default="default" | ||
) | ||
|
||
- #. Make sure that the field is always populated with a proper value in the new code, | ||
and the code handles the case where the field is null. | ||
|
||
.. code-block:: python | ||
|
||
if my_model.new_field in [None, "default"]: | ||
pass | ||
|
||
|
||
# If it's a boolean field, make sure that the null option is removed from the form. | ||
class MyModelForm(forms.ModelForm): | ||
def __init__(self, *args, **kwargs): | ||
super().__init__(*args, **kwargs) | ||
self.fields["new_field"].widget = forms.CheckboxInput() | ||
self.fields["new_field"].empty_value = False | ||
|
||
- #. Create the migration file (let's call this migration ``app 0001``), | ||
and mark it as ``Safe.before_deploy``. | ||
|
||
.. code-block:: python | ||
|
||
from django.db import migrations, models | ||
from django_safemigrate import Safe | ||
|
||
|
||
class Migration(migrations.Migration): | ||
safe = Safe.before_deploy | ||
|
||
- #. Create a data migration to populate all null values of the new field with a proper value (let's call this migration ``app 0002``), | ||
and mark it as ``Safe.after_deploy``. | ||
|
||
.. code-block:: python | ||
|
||
from django.db import migrations | ||
|
||
|
||
def migrate(apps, schema_editor): | ||
MyModel = apps.get_model("app", "MyModel") | ||
MyModel.objects.filter(new_field=None).update(new_field="default") | ||
|
||
|
||
class Migration(migrations.Migration): | ||
safe = Safe.after_deploy | ||
|
||
operations = [ | ||
migrations.RunPython(migrate), | ||
] | ||
|
||
- #. After the deploy has been completed, create a new migration to set the field as non-nullable (let's call this migration ``app 0003``). | ||
Run this migration on a new deploy, you can mark it as ``Safe.before_deploy`` or ``Safe.always``. | ||
- #. Remove any handling of the null case from the code. | ||
|
||
At the end, the deploy should look like this: | ||
|
||
- Deploy web-extra. | ||
- Run ``django-admin safemigrate`` to run the migration ``app 0001``. | ||
- Deploy the webs | ||
- Run ``django-admin migrate`` to run the migration ``app 0002``. | ||
- Create a new migration to set the field as non-nullable, | ||
and apply it on the next deploy. | ||
stsewd marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
Removing a field | ||
---------------- | ||
|
||
**When removing a field from a model, | ||
all usages of the field should be removed from the code before the field is removed from the model, | ||
and the field should be nullable.** | ||
You can achieve this by following these steps: | ||
|
||
- #. Remove all usages of the field from the code. | ||
- #. Set the field as ``null=True`` and ``blank=True`` in the model. | ||
|
||
.. code-block:: python | ||
|
||
class MyModel(models.Model): | ||
field_to_delete = models.CharField(max_length=100, null=True, blank=True) | ||
|
||
- #. Create the migration file (let's call this migration ``app 0001``), | ||
and mark it as ``Safe.before_deploy``. | ||
|
||
.. code-block:: python | ||
|
||
from django.db import migrations, models | ||
from django_safemigrate import Safe | ||
|
||
|
||
class Migration(migrations.Migration): | ||
safe = Safe.before_deploy | ||
|
||
- #. Create a migration to remove the field from the database (let's call this migration ``app 0002``), | ||
and mark it as ``Safe.after_deploy``. | ||
|
||
.. code-block:: python | ||
|
||
from django.db import migrations, models | ||
from django_safemigrate import Safe | ||
|
||
|
||
class Migration(migrations.Migration): | ||
safe = Safe.after_deploy | ||
|
||
At the end, the deploy should look like this: | ||
|
||
- Deploy web-extra. | ||
- Run ``django-admin safemigrate`` to run the migration ``app 0001``. | ||
- Deploy the webs | ||
- Run ``django-admin migrate`` to run the migration ``app 0002``. |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,32 @@ | ||
# Generated by Django 4.2.9 on 2024-02-01 20:29 | ||
|
||
import datetime | ||
|
||
from django.db import migrations | ||
from django_safemigrate import Safe | ||
|
||
|
||
def migrate(apps, schema_editor): | ||
""" | ||
Migrate the created and modified fields of the Version model to have a non-null value. | ||
|
||
This date corresponds to the release date of 5.6.5, | ||
when the created field was added to the Version model | ||
at https://github.com/readthedocs/readthedocs.org/commit/d72ee6e27dc398b97e884ccec8a8cf135134faac. | ||
""" | ||
Version = apps.get_model("builds", "Version") | ||
date = datetime.datetime(2020, 11, 23, tzinfo=datetime.timezone.utc) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Shouldn't we use a date that it's obvious it's wrong to avoid confusions here? Like There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think that would add more confusion, for us and users (if we expose this field). |
||
Version.objects.filter(created=None).update(created=date) | ||
Version.objects.filter(modified=None).update(modified=date) | ||
|
||
|
||
class Migration(migrations.Migration): | ||
safe = Safe.before_deploy | ||
|
||
dependencies = [ | ||
("builds", "0056_alter_versionautomationrule_priority"), | ||
] | ||
|
||
operations = [ | ||
migrations.RunPython(migrate), | ||
] |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,37 @@ | ||
# Generated by Django 4.2.9 on 2024-02-01 20:38 | ||
|
||
import django.utils.timezone | ||
import django_extensions.db.fields | ||
from django.db import migrations | ||
from django_safemigrate import Safe | ||
|
||
|
||
class Migration(migrations.Migration): | ||
safe = Safe.after_deploy | ||
|
||
dependencies = [ | ||
("builds", "0057_migrate_timestamp_fields"), | ||
] | ||
|
||
operations = [ | ||
migrations.AlterField( | ||
model_name="version", | ||
name="created", | ||
field=django_extensions.db.fields.CreationDateTimeField( | ||
auto_now_add=True, | ||
default=django.utils.timezone.now, | ||
verbose_name="created", | ||
), | ||
preserve_default=False, | ||
), | ||
migrations.AlterField( | ||
model_name="version", | ||
name="modified", | ||
field=django_extensions.db.fields.ModificationDateTimeField( | ||
auto_now=True, | ||
default=django.utils.timezone.now, | ||
verbose_name="modified", | ||
), | ||
preserve_default=False, | ||
), | ||
] |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,37 @@ | ||
# Generated by Django 4.2.9 on 2024-02-01 20:10 | ||
|
||
import django.utils.timezone | ||
import django_extensions.db.fields | ||
from django.db import migrations | ||
from django_safemigrate import Safe | ||
|
||
|
||
class Migration(migrations.Migration): | ||
safe = Safe.always | ||
stsewd marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
dependencies = [ | ||
("integrations", "0012_migrate_timestamp_fields"), | ||
] | ||
|
||
operations = [ | ||
migrations.AlterField( | ||
model_name="integration", | ||
name="created", | ||
field=django_extensions.db.fields.CreationDateTimeField( | ||
auto_now_add=True, | ||
default=django.utils.timezone.now, | ||
verbose_name="created", | ||
), | ||
preserve_default=False, | ||
), | ||
migrations.AlterField( | ||
model_name="integration", | ||
name="modified", | ||
field=django_extensions.db.fields.ModificationDateTimeField( | ||
auto_now=True, | ||
default=django.utils.timezone.now, | ||
verbose_name="modified", | ||
), | ||
preserve_default=False, | ||
), | ||
] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't this migration be created in the same deploy and marked as
after_deploy
to make everything in the same deploy?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if that will work, but we still need to another deploy to remove all handling of the null case in the code.