Maintaining the db¶

Updating the db¶

If someone pushes changes that change the db, you’ll need to apply the new migrations to your db. Do this:

./manage.py migrate

Creating a schema migration¶

To create a new migration the automatic way:

make your model changes
run:
```
./manage.py makemigrations <app>
```
where <app> is the app name (base, feedback, analytics, ...).
add a module-level docstring to the new migration file specifying what it’s doing since we can’t easily infer that from the code because the code shows the new state and not the differences between the old state and the new stage
run the migration on your machine:
```
./manage.py migrate
```
run the tests to make sure everything works
add the new migration files to git
commit

Creating a data migration¶

Creating data migrations is pretty straight-forward in most cases.

To create a data migration the automatic way:

run:
```
./manage.py makemigrations --empty <app>
```
where <app> is the app name (base, feedback, analytics, ...)
edit the data migration you just created to do what you need it to do
make sure to add reverse_code arguments to all RunPython operations which undoes the changes
add a module-level docstring explaining what this migration is doing
run the migration forwards and backwards to make sure it works correctly
add the new migration file to git
commit

Data migrations for data in non-Fjord apps¶

If you’re doing a data migration that adds data to an app that’s not part of Fjord, but is instead a library (e.g. django-waffle), then create the data migration in the base app and add a dependency to the latest migration in the library app.

For example, this adds a dependency to django-waffle’s initial migration:

class Migration(migrations.Migration):

    dependencies = [
        ...
        ('waffle', '0001_initial'),
        ...
    ]

Quick search