15đź‘Ť
Here’s the process I used:
-
Roll back the code to the revision that created the fixture in the first place. For example:
svn up -r12345
. -
Empty the database, then create it with
manage.py syncdb --noinput --migrate
-
Load the fixture with
manage.py loaddata my_fixture.json
-
Roll the code forward to now, with
svn up
-
Migrate the database with
manage.py migrate
-
Dump the data with
manage.py dumpdata --indent=2 myapp >my_fixture.json
Note that you need to be careful when choosing the past revision to roll back to. In my case, I had some recent fixes that needed to be in place, so I actually had to pick and choose directories to roll back to specific revisions. Tedious, but better than hand-editing a 9,000-line JSON file.
Also, in step 6, be sure to dump the correct set of applications.
In the future, as I write migrations, I can do these steps again to keep all the fixtures up-to-date.
1đź‘Ť
Why can’t you simply create a fresh .json
file from your db. This is what I do when I need to create a new fixture.
python manage.py dumpdata <your_app> auth > test_data.json
- [Django]-How to force Django models to be released from memory
- [Django]-Django-allauth: Linking multiple social accounts to a single user
- [Django]-Uninstall Django completely
-3đź‘Ť
What’s the best way to move my fixtures forward as I migrate my database?
It’s too late.
As you migrate your database you need to loaddata
and dumpdata
.
One it stops working, it’s too late.
A possible fallback is to write a short script to load the JSON fixtures into memory,
and then “manually” build database objects.
with open( "somefile.json", "r" ) as data:
for obj in json.load( data ):
if obj['model'] == 'someapp.somemodel':
SomeNewModel.objects.create(
field = obj['fields']['element']
...
)
With something along those lines, you might be able to construct a database using your current schema and legacy fixtures.
- [Django]-UUID as default value in Django model
- [Django]-Determine variable type within django template
- [Django]-Django – Website Home Page