initial_data fixture management in django

Question

The django projet I'm working on has a ton of initial_data fixture data. It seems by default the only way to have data load automatically is to have a file in your app folder called fixtures, and the file needs to be named initial_data.ext (ext being xml or json or yaml or something).

This is really unflexable, I think. I'd rather have a fixtures folder, and then inside that a initial_data folder, and then inside there, one file for each model in that app. Or something to that effect. IS this possible to do in django now? Or maybe some other scheme of better fixture organization.

Infantile

Answer 1

In my experience, hard-coded fixtures are a pain to write and a pain to maintain. Wherever a model change breaks a fixture, the Django initial load will return a very unfriendly error message and you will end-up adding a bunch a of print's in the Django core in order to find where the problem is coming from.

One of the developer I work with has developed a very good library to overcome this problem, it's called django-dynamic-fixture and we really to love it. Here is how it works:

Suppose you have this models:

class Author(models.Model):
    name = models.CharField()

class Book(models.Model):
    author = models.ForeingKey(Author, required=True)
    title = models.CharField()

In order to create a book instance in your test, all you have to do is

from django_dynamic_fixture import get
from app import Book

class MyTest(TestCase):
    def setUp(self):
        self.book = get(Book)

The django-dynamic-fixture automatically creates for you any dependencies that are required for the Book model to exist. This is just a simple example but the library can handle very complex model structures.

Aglaia

how do you go about handling setup and teardown, specifically while working with djano-nose? – Cervantez

@Cervantez I am not sure what you asked. The example I gave already has a setUp example. Using django-nose would not change that – Aglaia

inside a class, before and after running each of the test definitions, the method setUp and tearDown are called. Which causes the tests to go slow. django_nose, however optimizes, it. Please refer to the doc. I was just curious how would you take care of those optimizations using DDF. – Cervantez

Answer 2

You can reorganize your initial data fixtures however you want and then write a post_syncdb signal handler which loads them. So it will then be automatically loaded on syncdb, according to the logic defined by you.

See: https://docs.djangoproject.com/en/1.3/ref/signals/#post-syncdb

Thanet

Answer 3

Yes, you can split fixtures into multiple files with subfolder structures. You can specify fixture files to load and create a script that loads some or all of them. I have done this before so can confirm that it works.

Example: django-admin.py loaddata application/module/model.json

See loaddata documentation for more information.

Multidisciplinary

nbv4: I found that most convenient method for dealing with this issue while developing is to create a database reset script that will first clear the database (database dependent), then create database structures (syncdb) and finally load fixtures (loaddata). – Multidisciplinary

Answer 4

A hacky way to load an additional initial_data.json or two is to create additional empty apps within your Django project that has nothing but the fixtures folder and the initial_data.json file. If you need the fixture loaded before the other apps' fixtures, you could name it something like aa1. If you need another one you could name it aa2. Your directory structure would look like this:

aa1/
   fixtures/
      initial_data.json

aa2/
   fixtures/
      initial_data.json

myrealapp/
   fixtures/
      initial_data.json
...

You would need to add the apps to INSTALLED_APPS in settings.py.

You can then populate the fixture_data.json files with arbitrary app information as necessary:

(virtualenv) ./manage.py dumpdata --indent=4 auth > aa1/fixtures/initial_data.json

(virtualenv) ./manage.py dumpdata --indent=4 oauth2 > aa2/fixtures/initial_data.json

(virtualenv) ./manage.py dumpdata --indent=4 myrealapp > myrealapp/fixtures/initial_data.json

When you run python manage.py syncdb, each of the fixtures will be loaded in automatically in alphabetical order.

As I mentioned, this is quite hacky, but if you only need a couple extra initial_data.json files and need to be able to control the order they are loaded in, this works.

Cure