Skip to main content

KHE

Reminders About the Use of South with Satchmo

Kenneth H. East [view page source]

Getting Started

You have already installed Satchmo and have been working on an application. You have yet to use South on the project...

  1. pip install south

  2. Add south to INSTALLED_APPS

  3. Make sure that the DB tables needed by South itself get created: ./manage.py syncdb

  4. Satchmo already has South migrations that are included in the South source. These are installed when South is installed. But since we just recently installed South, there are really no migrations to perform -- i.e., the DB schema already looks like Satchmo expects it to. Therefore, we do a fake migration: ./manage.py migrate --fake

  5. If you run ./manage.py migrate --list, you'll see a bunch of migrations that South thinks were applied, but that were only faked. This is good.

    In terms of the output, migrations marked (*) have been applied, and those marked ( ) have not been applied.

NOTE: In my case, I had not created a model yet for the Satchmo
application. I ran ./manage.py convert_app store.localsite, but received an error message that complained because the app had no models. No models == nothing to migrate / nothing to fake. Had there been models, then convert_app would have been needed, I think.

Deployment

Assume for this example, that you did an initial app deployment with no schema changes, and that the app has been up and running for months, the DB filling with data.

Ongoing Development

While your app was working away, so were you, you've been developing R2 of the app. And R2 needs new object classes / schema changes. On your development system:

  1. Add an object to store/localsite/models.py.
  2. Prior to using South, you would now sync the DB so that Django/Satchmo can see/use it via ./manage.py syncdb. If you do that now, you'll see a message that store.localsite was not synced and that you must use a South migration.
  3. Create the initial South migration via ./manage.py schemamigration store.localsite --initial
  4. Now, apply the migration to the DB: ./manage.py migrate store.localsite.
  5. Start Django and save some new objects in your new table.

If you decide that you need to make further schema changes, that's fine -- go ahead. After each change, follow these steps:

  1. Create a new migration for the change via ./manage.py schemamigration store.localsite --auto.
  2. Apply the migration to the DB: ./manage.py migrate store.localsite.
  3. Start Django and use your changes.

Assume that you are now ready to release R2. Your development schema is, by definition, up-to-date, as are the series of migrations that you have created.