Will >> Will's blog
Wed, 11 Sep 2013
We just landed the bits that switch us from Schematic---the migration system we were using---to South. This is my account of that journey in case it helps others.
Schematic has the nicety of being very very raw. You can do anything: raw SQL, raw shell, raw Python, raw fish---whatevs. This was nice because we could write whatever we wanted.
Schematic is a total pain in the ass because it hasn't been touched in 2 years, doesn't work well with recent versions of MySQL or MariaDB and makes it really difficult to write migrations that continue to work over time. Further, there's no way to do backwards migrations in Schematic even if you wanted to. We were constantly getting bit by these issues.
Switching from Schematic to South turned out to be pretty easy. I did it Monday afternoon. I essentially followed these steps:
Added South as a dependency for our Django project.
Initialized South migrations for all the apps we use in Kitsune which was a whole bunch of:
$ ./manage.py schemamigration <appname> --initial
Wrote a last Schematic migration that adds all the South bookkeeping which entailed dumping the output of this to a file:
$ mysqldump <database> south_migrationhistory
and then editing that file by hand.
That creates the south_migrationhistory table and populates it with the bookkeeping for the initial commits for the apps initialized in step 2.
Added ./manage.py migrate to our deploy script.
Do a happy dance!
The relevant commits for Kitsune are here:
- fa412aa2 [bug 911831] Add initial South migrations
- 0884893b [bug 911831] Update deployment script with South
- cde04df1 [bug 911831] Update db and migration docs for South
- 609144f2 Quell south logging during tests
That's pretty much it.
- Update: September 11, 2013
- This was with Django 1.4.7 and South 0.8.2. If you're using different versions, you may experience different things.
- Update: September 13, 2013
In Schematic, one thing we would do after creating new models is add a content type and the permissions.
This walks through setting that up automatically with South and post_migrate:
Sat, 16 Feb 2013
Django Eadred gives you some scaffolding for generating sample data to make it easier for new contributors to get up and running quickly, bootstrapping required database data, and generating large amounts of random data for testing graphs and things like that.
For v0.2, I added some helper methods for generating names, email addresses, sentences and paragraphs. It's definitely the case that these helpers won't handle all use cases, but I think they'll help specific ones.
There are no backwards-compatability problems with v0.1.
To update, do:
pip install -U eadred
Tue, 16 Oct 2012
I work on a few projects that had a need for generating sample data to make it easier for new contributors to get up and running quickly with little effort. These projects are fairly data-driven---they're kind of useless without data.
Then we had a hankering for it in SUMO, plus I thought it made sense to turn it into its own app. So I spun it out into its own project.
Thus django-eadred was born.
Generally, it allows you to define a sampledata.py module with a generate_sampledata function that takes command line options to generate sample data for any app you want to generate sample data for.
You can use it to define different ways of generating sample data specified by the command line.
You can use it to generate random data, non-random data, initial data, data for contributors, sample data for large data sets, fixture data, etc.
Check out django-eadred.readthedocs.org for use cases, documentation and project details.