dumpdata generates python source code files as the fixtures
Project description
# About
Django fixtures can lead to maintenance problems. You often forget to update them when you refactor your models. Other times, you have to try to fix them by hand and find yourself in a morass of primary keys. In general, they are fragile.
Many experts suggest that you forgo fixtures and write your own object factories. Great idea! Here is a tool to help you get started. Using the regular Django `dumpdata` command, pyfixtures will generate a python file that contains all the code necessary to re-constitute that data in an empty database. You can take that code and refactor it into something you maintain going forward, or you can re-generate it from a target database when needed.
# Install
### Add to INSTALLED_APPS
In your `settings.py`, add `pyfixtures` to the INSTALLED_APPS setting:
```python
INSTALLED_APPS = (
...
'pyfixtures',
)
```
### Set SERIALIZATION_MODULES
```bash
SERIALIZATION_MODULES = {'py': 'pyfixtures.serializer'}
```
# Usage
Use the regular Django dumpdata command, but with the format set to pyfixtures.
```bash
./manage.py dumpdata --exclude contenttypes --format=py > fixtures/initial_data.py
```
You can also use the `loaddata` command on that file, as you would expect.
```bash
./manage.py loaddata fixtures/initial_data.py
```
# Settings
```bash
PYFIXTURES_CIRCULAR_DEP_BREAKERS = ('Organization', 'Group', 'WorkflowHistory')
```
If you run into problems serializing your models due to circular dependencies, pyfixtures will prompt you to "break the tie" by designating one or more of your models to use primary keys directly in the constructors.
You'll know if you need to use this setting if you see something like the following when you run dumpdata:
```bash
InfractionType depends on ['WorkflowItem']
WorkflowItem depends on ['WorkflowHistory']
WorkflowHistory depends on ['WorkflowItem']
Error: Unable to serialize database: Could not sort objects in dependency order, is there a circular dependency?
```
# Writing Your own Fixtures
The fixtures are mostly what you would expect. You import models that you need, and declare your objects. The fixtures that we generate don't use loops, but you can if you want to.
Because Django's `loaddata` command expects to save the models itself, we don't call `save()` on the models directly in the fixture. Instead, anything you define in the scope of the fixture file that inherits from Django's Model class will be saved when `loaddata` runs.
This is slightly at odds with how many to many relationships work in Django. Normally, you would structure your code like this:
```python
from django.db import models
class Publication(models.Model):
title = models.CharField(max_length=30)
class Article(models.Model):
headline = models.CharField(max_length=100)
publications = models.ManyToManyField(Publication)
p1 = Publication(title='The Python Journal')
p1.save()
a1 = Article(headline='Django lets you build Web apps easily')
a1.publications.add(p1)
```
Because we need to defer the saving of your models, we use the following mechanism to declare many to many relationships. You should follow this convention if you write your own fixtures.
```python
p1 = Publication(title='The Python Journal')
a1 = Article(headline='Django lets you build Web apps easily')
a1.m2m_data = {'publications': [p1]}
```
Django fixtures can lead to maintenance problems. You often forget to update them when you refactor your models. Other times, you have to try to fix them by hand and find yourself in a morass of primary keys. In general, they are fragile.
Many experts suggest that you forgo fixtures and write your own object factories. Great idea! Here is a tool to help you get started. Using the regular Django `dumpdata` command, pyfixtures will generate a python file that contains all the code necessary to re-constitute that data in an empty database. You can take that code and refactor it into something you maintain going forward, or you can re-generate it from a target database when needed.
# Install
### Add to INSTALLED_APPS
In your `settings.py`, add `pyfixtures` to the INSTALLED_APPS setting:
```python
INSTALLED_APPS = (
...
'pyfixtures',
)
```
### Set SERIALIZATION_MODULES
```bash
SERIALIZATION_MODULES = {'py': 'pyfixtures.serializer'}
```
# Usage
Use the regular Django dumpdata command, but with the format set to pyfixtures.
```bash
./manage.py dumpdata --exclude contenttypes --format=py > fixtures/initial_data.py
```
You can also use the `loaddata` command on that file, as you would expect.
```bash
./manage.py loaddata fixtures/initial_data.py
```
# Settings
```bash
PYFIXTURES_CIRCULAR_DEP_BREAKERS = ('Organization', 'Group', 'WorkflowHistory')
```
If you run into problems serializing your models due to circular dependencies, pyfixtures will prompt you to "break the tie" by designating one or more of your models to use primary keys directly in the constructors.
You'll know if you need to use this setting if you see something like the following when you run dumpdata:
```bash
InfractionType depends on ['WorkflowItem']
WorkflowItem depends on ['WorkflowHistory']
WorkflowHistory depends on ['WorkflowItem']
Error: Unable to serialize database: Could not sort objects in dependency order, is there a circular dependency?
```
# Writing Your own Fixtures
The fixtures are mostly what you would expect. You import models that you need, and declare your objects. The fixtures that we generate don't use loops, but you can if you want to.
Because Django's `loaddata` command expects to save the models itself, we don't call `save()` on the models directly in the fixture. Instead, anything you define in the scope of the fixture file that inherits from Django's Model class will be saved when `loaddata` runs.
This is slightly at odds with how many to many relationships work in Django. Normally, you would structure your code like this:
```python
from django.db import models
class Publication(models.Model):
title = models.CharField(max_length=30)
class Article(models.Model):
headline = models.CharField(max_length=100)
publications = models.ManyToManyField(Publication)
p1 = Publication(title='The Python Journal')
p1.save()
a1 = Article(headline='Django lets you build Web apps easily')
a1.publications.add(p1)
```
Because we need to defer the saving of your models, we use the following mechanism to declare many to many relationships. You should follow this convention if you write your own fixtures.
```python
p1 = Publication(title='The Python Journal')
a1 = Article(headline='Django lets you build Web apps easily')
a1.m2m_data = {'publications': [p1]}
```
Project details
Release history Release notifications | RSS feed
Download files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
Source Distribution
django-pyfixtures-0.1.tar.gz
(6.0 kB
view hashes)