[PATCH 0/3] Fix migrations state & load initial data throuh migrations (v2)
stephen.finucane at intel.com
Wed Sep 9 23:50:57 AEST 2015
> I honestly don't think either of them is much worse of much better. One
> needs to land though :)
Yes, patches in general need to land :)
> 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.
Right you are. This is still an antipattern though: what if the user wants to change the loaded data at some point in the future? Should they create a new migration? I'm just not gone on the whole idea...
> 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.
I've yet to find any patchwork instance that uses anything but the default states and tags, hence the suggestion to move to 'choices'. However, as you say both solutions solve the more pressing issue of quashing this bug.
More information about the Patchwork