StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>I find that it is best to keep any fixtures I have in line with the current version of the code. So upon creating migration 0003 you do a <a href="http://south.aeracode.org/docs/tutorial/part3.html#data-migrations" rel="nofollow">data migration</a> and a new <code>dumpdata</code>, replacing fixture 0002. When you create your data migration, make sure you do both forwards and backwards, that way you'll end up with the correct data when you migrate back to 0002.</p> <p>When you do the data migration, make sure you access all models through the <code>orm</code> object, otherwise you end up with errors similar to what you're already experiencing.</p> <p>If you want to actually run your django code with the old data (version 0002) for some reason, then your models need to match your database. That would mean checking out an appropriate version of the code using whatever code versioning you're using (git, hg, svn...). If you're trying to solve a problem "back in time" you probably want to branch at that point too.</p> <p>See also <a href="http://south.aeracode.org/docs/fixtures.html" rel="nofollow">south's documentation comments on fixtures</a></p> <p>Here's an idea, inspired by that link above: "the best thing to do is to write a new migration to load the fixture in". What about loading your fixture (which you already have) from a migration, rather than <code>loaddata</code>. You would still need to create a data migration and use the <code>orm</code> object to manually load the data. You can make use of django's <a href="http://docs.djangoproject.com/en/1.3/topics/serialization/" rel="nofollow">serialization functions</a>, which is exactly what <code>loaddata</code> <a href="http://code.djangoproject.com/browser/django/trunk/django/core/management/commands/loaddata.py#L168" rel="nofollow">does</a>.</p> <p>With respect to why <code>loaddata</code> uses the model version and not the database version: <code>loaddata</code> is a <a href="http://docs.djangoproject.com/en/dev/ref/django-admin/#loaddata-fixture-fixture" rel="nofollow">django management command</a>, with no knowledge of what south is doing. Because of that, it needs to remain database agnostic and use django's ORM. You can always <a href="http://docs.djangoproject.com/en/dev/howto/custom-management-commands/" rel="nofollow">write your own management command</a> if you need to do something more specific - potentially pulling out some of south's orm versioning, or doing a database specific loaddata that reads the schema directly from the database. I think the solution in the previous paragraph will be a lot less work though.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload