davedash/django-fixture-magic

Requirements

This package requires:

• Python 2.7, 3.6
• Django 1.8 - 2.1

Installation

You can get fixture-magic from pypi with:

pip install django-fixture-magic

The development version can be installed with:

pip install -e git://github.com/davedash/django-fixture-magic#egg=fixture-magic

For use in python3 install the following:

pip install future

fixture-magic adds two commands to manage.py therefore you should add it to your INSTALLED_APPS in settings.py:

INSTALLED_APPS = (
    ...
    'fixture_magic',
    ...
)

Usage

There are four commands. dump_object returns the json representation of a specific object as well as all its dependencies (as defined by ForeignKeys):

./manage.py dump_object APP.MODEL PK1 PK2 PK3 ... > my_new_fixture.json

Or:

./manage.py dump_object APP.MODEL --query '{"pk__in": [PK1, PK2, PK3]}' > my_new_fixture.json

Or you can get all objects with all dependencies by passing an asterisk:

./manage.py dump_object APP.MODEL '*' > my_new_fixture.json

You can now safely load my_new_fixture.json in a test without foreign key i errors.

By default, fixture magic will dump related fixtures to your model in your fixture. This can be disabled by passing the option --no-follow to dump_object. This is useful if your target database is already partially setup. Here is and example default output of dump_object:

./manage.py dump_object APP.Book

[
  {
      "model": "APP.Author",
      "fields": {
          "pk": 5,
          "name": "Mark Twain",
      }
  },
  {
      "model": "APP.Book",
      "fields": {
          "pk": 2,
          "title": "Tom Sawyer",
          "author": 5
      }
  }
]

Running with the --no-follow options yields:

./manage.py dump_object APP.Book --no-follow

[
  {
      "model": "APP.Book",
      "fields": {
          "pk": 2,
          "title": "Tom Sawyer",
          "author": 5
      }
  }
]

The second command is merge_fixtures. This command takes several fixture files and does a simple de-dupe operation (based on model and pk) and returns a clean json file. This is helpful if you have multiple json fixtures that might have redundant data:

./manage.py merge_fixtures fixture1.json fixture2.json fixture3.json ... \
> all_my_fixtures.json

The third command is reorder_fixtures. This command takes a single file and several model names (in app.model format as they are specified in fixture files). This reorders your fixtures so the models you specifiy first show up in the fixture first. This is helpful if you tend to get foreign-key errors when loading models:

./manage.py reorder_fixtures fixture.json APP1.MODEL1 APP2.MODEL2 ... \
> ordered_fixture.json

Unspecified models will be appended to the end.

The fourth command is custom_dump. This reads a setting CUSTOM_DUMPS:

## Fixture Magic
CUSTOM_DUMPS = {
    'addon': {  # Initiate dump with: ./manage.py custom_dump addon id
        'primary': 'addons.addon',  # This is our reference model.
        'dependents': [  # These are the attributes/methods of the model that we wish to dump.
            'current_version',
            'current_version.files.all.0',
        ],
        'order': ('app1.model1', 'app2.model2',),
        'order_cond': {'app1.model1': lambda x: 1 if x.get('fields').get('parent_model1') else 0,
                        'app2.model2': lambda x: -1 * x.get('pk')},
    }
}

It runs the equivalent of dump_object on the dependents (which in turn pick up the primary object). The JSON dumps are then merged together. Very handy for dumping multi-dependent objects. dependents, order and order_cond are optional.

dependents: Defines additional properties/methods to dump the return values of. Magic will convert "current_version.files.all.0" to object.current_version.files.all()[0]

order: Specify an order in which objects should be dumped based on their model class. In the above example, all app1.model1 objects will preceed any app2.model2 objects, which will preceed any objects of any other model class.

order_cond: Specify an order to dump objects of one or more particular model classes. In the above example, all app1.model1 objects with a truthy self.parent_model1 attribute will come after any other app1.model1 object that does not have a truthy value for this attribute. A sort operation is called on the list of all objects of that model type, with the value associated with a model name being passed to the sort function as the key keyword argument. Keep in mind that the model objects will have already been serialized to a dictionary object prior to the sort operation.