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:
That's pretty much it.
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:
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
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.
Copyright 1996 to 2013, Will Guaraldi Kahn-Greene, under the Creative Commons BY-SA 3.0 license
Will's Blog by William Kahn-Greene is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.