translate/pootle — pull request #96 by dwaynebailey (2013-05-23 11:00:34+00:00)
Title: Pootle 2.5.1 initiailing from scratch with South

This is a first draft of starting a Pootle DB from scratch on master
================================================

Background
----------------
The move to South lost us the easy of running Pootle form first install:

``pip install pootle``
``pootle init``
``pootle start``

Now in ``master`` you have an added step of ``manage.py migrate``, things are clear an manageable for a Pootle that is migrating from 2.5.0 but not for one starting on 2.5.1.

We get a number of tracebacks.

The Issue
--------------
Pootle makes use of the post_syncdb signal and the ``post_syncdb_handler`` in ``pootle_app/managemenet/__init__.py``. This worked previously because ``post_syncdb`` signal occurs after ``syncdb`` command. Now with South, ``post_syndb`` signal will happen after each app migration. We don't have, much, control over which objects get created so we end up with some tables not having been created before we need them.

The Solution(s)
--------------------
I've tried the following:

1. *Tried*: Adding migration logic to ``0001_initial.py`` migrations - doesn't work since we don't have access to the model. Which explains why they do schema and data migrations apart.
2. *This PR*: Add additional 0002 migrations using fixtures. Fixtures being JSON code of the data. One thing I don't like about this is that I'm having to specify primary keys.
3. *Could have done*: To late now but I suspect if ``pootle_app``'s 0001 migration was broken down a little more we could have used the South depends_on options to ensure proper dependencies and left our post_syncdb approach as is.
4. *Haven't tried*: Using ``post_syncdb`` signals in the relevant apps. This would mean moving code from ``pootle_app`` to the relevant apps. What I do like about this approach is that we then have full access to our models.

Concerns
-------------
My current concerns with the fixtures approach is that it just feels brittle. We can't rely on any model methods since South can only work with the data. So e.g. creating a User triggers the creation of a PootleProfile. So in fixtures we need to ensure we have both a User and a PootleProfile. Plus supply primary keys.

So I'm still wonder if option 4 above would be better. With our current logic we would only create missing data (remember post synd_db will run every time we do a migration) and we'd then create it programmatically, so no dumb fixtures and no dumb South migration scripts.