[PATCH 0/3] Fix migrations state & load initial data throuh migrations (v2)

[Damien Lespiau]

On Wed, Sep 09, 2015 at 02:21:48PM +0100, Finucane, Stephen wrote:
> > v2 of the previous series (long explanation there):
> > 
> >   https://lists.ozlabs.org/pipermail/patchwork/2015-August/001394.html
> > 
> > This time passing the tests.
> 
> Could you use a prefix next time ('--prefix="PATCH v2"' option in git-send-mail) - it's quite confusing to find the correct version otherwise.
> 
> > I've now also noticed that Stephen fixed the same issue in a different way
> > in:
> > 
> >   https://lists.ozlabs.org/pipermail/patchwork/2015-July/001362.html
> > 
> > I like my solution slightly better, but that's debatable, of course.
> 
> I considered taking the approach taken here. However, I read an
> article detailing why Django 1.8+ removed support for "initial
> fixtures" (which I, of course, can't find the link for now...). In
> summary, use of initial fixtures causes whatever data is in the
> database to be overwritten with the fixtures. This doesn't fit into
> the paradigm of "migrations", which should modify data based on
> explicitly defined instructions only. I think the reason we use
> fixtures is because end users will have different (and changing)
> requirements for their states and tags. Explicitly having to load
> fixtures reinforces this idea (you load *your* fixtures, which could
> provide the same tags/states as the upstream, or could be modified).
> If this isn't true and users are expected not to modify these, then we
> should probably look at migrating to a field with 'choices' instead.
> 
> tl;dr: I prefer my approach

I honestly don't think either of them is much worse of much better. One
needs to land though :)

If you notice closely, I don't rely on automatic fixture loading, just
that was was before automatically loaded in the db (states, tags, ...)
are now a migration step (step 0002 in my series). That's one way to
address initial fixture being deprecated.

The point that, in theory, users can load their own data for those
tables, but I don't think it really matter in practice with the deployed
patchwork instances I'm aware of.

-- 
Damien