[PATCH 0/3]

Damien Lespiau damien.lespiau at intel.com
Wed Aug 19 03:30:17 AEST 2015


Hi all,

When playing with the new migration system (by the way, switching to django 1.7
and above means I need to rebase all my work touching the db, that will teach
me to have long-lived branches not upstreamed :), I've discovered that there's
a problem with the current lone migration step (0001).

The models have one change on top of 0001: the default value of Patch.state
that requires to have the State table populated. However State isn't populated
until we load the fixture files into the db. So when deploying a new instance
of patchwork one needs to:

 1/ apply 0001
 2/ populate State by loading the fixtures

We're then left in a weird state where the migration system isn't reflecting
the current models.py: "manage.py migrate" isn't clean and gives a warning:

  "Your models have changes that are not yet reflected in a migration, and so
   won't be applied."

And indeed "manage.py makemigrations" tells us we're missing something in 0001.

  class Migration(migrations.Migration):

      dependencies = [
          ('patchwork', '0001_initial'),
      ]

      operations = [
          migrations.AlterField(
              model_name='patch',
              name='state',
              field=models.ForeignKey(default=patchwork.models.get_default_initial_patch_state, to='patchwork.State'),
          ),
      ]

In addition django 1.9 is going to remove initial data through fixtures:

  If an application uses migrations, there is no automatic loading of fixtures.
  Since migrations will be required for applications in Django 1.9, this
  behavior is considered deprecated. If you want to load initial data for an
  app, consider doing it in a data migration.

  Source: https://docs.djangoproject.com/en/1.8/howto/initial-data/

So, this series adds 2 more migration steps:

  0002 -> populate a few tables with initial data, 
  0003 -> apply the migration step that adds the default value for Patch.state

Note that 0002 will be already applied on existing instances since the data in
the fixture files should already be there. Since django 1.8, manage.py migrate
has a --fake flag that can be used to mark 0002 as applied without trying to
do the SQL changes.

After this series, the migration state is clean, ready to be used for db
management.

-- 
Damien

Damien Lespiau (3):
  migrations: Use a data migration to load initial states and tags
  fixtures: Remove the initial project data
  migrations: Add the default value of Patch.state

 docs/INSTALL                                       |  5 ---
 patchwork/fixtures/default_projects.xml            | 18 -----------
 patchwork/migrations/0002_load_initial_data.py     | 37 ++++++++++++++++++++++
 .../migrations/0003_patch_state_default_value.py   | 20 ++++++++++++
 patchwork/models.py                                |  2 +-
 5 files changed, 58 insertions(+), 24 deletions(-)
 delete mode 100644 patchwork/fixtures/default_projects.xml
 create mode 100644 patchwork/migrations/0002_load_initial_data.py
 create mode 100644 patchwork/migrations/0003_patch_state_default_value.py

-- 
2.1.0



More information about the Patchwork mailing list