CODEWITHSUNDEEP
pythondjangofixture
priestc
priestc

Reputation: 35310

initial_data fixture management in django

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.

Upvotes: 6

Views: 4037

Answers (4)

Ryan Rapp
Ryan Rapp

Reputation: 1713

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.

Upvotes: 0

Cesar Canassa
Cesar Canassa

Reputation: 20253

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.

Upvotes: 10

Botond Béres
Botond Béres

Reputation: 16683

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

Upvotes: 2

vls
vls

Reputation: 2319

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.

Upvotes: 0

Related Questions