I want to remove all data from all models defined in a single Django app. The number of models might change in the app, hence I don't want to hard code model names. It would be great if it might be done using manage.py command, however I was not able to find one.
The manage.py flush command is not suitable, because it only allows to clear data from all apps.
If you are using django version greater than 1.7, which you are. You can simply use migrate zero command to drop from specific app. Like:
py manage.py migrate APPNAME zero
Here, APPNAME is name of the app from where you want to flush data.
Refs
Related
We are a team of developers working on Django project. We are facing issues with django migrations. if one developer makes changes in model and runs makemigrations>migrate sequence it generates some sqls in migrations directory. Now when other developer pulls the code, and run the same sequence it's putting code in bad state. We've been clearing our migrations directory locally to get rid of the issue, and sometimes clear all the data. Not sure what we're doing incorrectly. Please suggest the right way of using django migrations.
Note - All of us use separate instances of DB in local machine.
makemigrations just create files
By running makemigrations, you’re telling Django that you’ve made some changes to your models (in this case, you’ve made new ones) and that you’d like the changes to be stored as a migration.
Migrations are how Django stores changes to your models (and thus your database schema) - they’re just files on disk. You can read the migration for your new model if you like; it’s the file polls/migrations/0001_initial.py.
Under Version Control, after you push the migrations file, for example, 0001_initial.py. Other developers just pull the file then run
python manage.py sqlmigrate your_app 0001 # to see what happen
python manage.py migrate your_app 0001
More about the Version Control:
Version control
Because migrations are stored in version control, you’ll occasionally come across situations where you and another developer have both committed a migration to the same app at the same time, resulting in two migrations with the same number.
Don’t worry - the numbers are just there for developers’ reference, Django just cares that each migration has a different name. Migrations specify which other migrations they depend on - including earlier migrations in the same app - in the file, so it’s possible to detect when there’s two new migrations for the same app that aren’t ordered.
When this happens, Django will prompt you and give you some options. If it thinks it’s safe enough, it will offer to automatically linearize the two migrations for you. If not, you’ll have to go in and modify the migrations yourself - don’t worry, this isn’t difficult, and is explained more in Migration files below.
I've set up a new Django project (based on the template django cookie cutter) but get a postgres error when trying to migrate the database for the first time
psycopg2.ProgrammingError: relation "django_site_domain_a2e37b91_uniq" already exists
I'm not clear what the issue is or how best to diagnose?
What is SITE_ID?
Django was created from a set of scripts developed at a newspaper to
publish content on multiple domains; using one single content base.
This is where the "sites" module comes in. Its purpose is to mark
content to be displayed for different domains.
In previous versions of django, the startproject script automatically
added the django.contrib.sites application to INSTALLED_APPS, and when
you did syncdb, a default site with the URL example.com was added to
your database, and since this was the first site, its ID was 1 and
that's where the setting comes from.
Keep in mind that starting from 1.6, this framework is not enabled by
default. So if you need it, you must enable it
The SITE_ID setting sets the default site for your project. So, if you
don't specify a site, this is the one it will use.
Ways to fix this:
Increment SITE_ID:
1. Increment `SITE_ID` variable in settings.py
2. python manage.py makemigrations
3. python manage.py migrate --run-syncdb
Cons: Had to increment SITE_ID without good reason
Attempt to migrate without --run-syncdb:
1. python manage.py makemigrations
2. python manage.py migrate
Note: May have to try multiple times before it works. Unsure why, possibly because I was in the process of deleting the pvc
I have a custom django management command that initializes an apps migrations. Trouble is, south does not detect the new migrations in the command.
for app in custom_apps:
call_command('schemamigration', app, initial=True)
call_command('migrate', app, fake=True)
This creates the initial migration, but does not apply them.
? You have no migrations for the 'profile' app. You might want some.
I tried using convert_to_south, but it only converts the first app in the list, and then gives this error for the rest of them
This application has no models; this command is for applications that already have models syncdb'd.
Make some models, and then use ./manage.py schemamigration candidates --initial instead.
The commands work if I run them manually.
Can't figure out what's going on.
I think you are missing an argument to the migrate command.
See here) a small example for fake converting your app. Their command looks like this:
./manage.py migrate myapp 0001 --fake
So, you could try something like this:
for app in custom_apps:
call_command('schemamigration', app, initial=True)
call_command('migrate', 0001, fake=True)
If you want to convert all your apps at once, you could use this code outside your loop.
call_command('migrate', 0001, fake=True, all=True)
Normally, this last command should fake applying the initial migrations for all your apps.
Good luck.
What is the best solution if I want to upgrade (alter) my database schema (add new fields to tables by adding them just to Django models) without losing data in these tables? "syncdb" not adding them of course, so I need your advices how to alter tables without deleting them and recreating again with syncdb.
When south isn't an option I just manually write scripts for small changes. and big ones i use
./manage.py dumpdata appname
http://docs.djangoproject.com/en/dev/ref/django-admin/#dumpdata-appname-appname-appname-model
Throw that into a file. Run a regex replace to update any added /removed fields and then a reset of that app is possible. I have to admit i haven't done this in a while but i can get some specific code to do this for you if needed.
it loads back up with loaddata
edit
Django dump data for a single model? This Question is similar and might have the info i was talking about.
Still let me know if you need and i'll dig up my old script (or write out a nice simple one) for you.
UPDATE
./manage.py dumpdata appname --indent=4 > appname.json
#open your fav text editor and do a find/replace
./manage.py reset appname
./manage.py loaddata appname.json
That should do it. When you do a find replace you only need to remove fields that you don't have any more and add fields that aren't nullable. (as a minimum).
Notes: the --indent=4 nicely formats everything for you. It means 4 spaces.
the ./manage.py reset only works in pre django 1.3 (gah!) in django 1.3 you will have to do a ./manage dbshell and drop table. The sql for that is found from command ./manage.py sqlreset appname.
Learning curve...
http://south.aeracode.org/
South was merged into django core at version 1.7.
There is now a native django feature for data migration on schema changes.
Django 1.7 has built-in migrations support.
See https://docs.djangoproject.com/en/dev/releases/1.7/#schema-migrations
After making some changes in my models (eg. new field in a model and a new model) what is the best way of reflecting these changes to my populated database?
PS: I wanted to see many solutions in one place rated. Apparently more solutions are already listed here.
Another technique is to use the dumpdata and loaddata arguments to manage.py, killing your database in-between:
python manage.py dumpdata > dump.json
With an external tool, drop any affected tables, or kill the whole db
python manage.py loaddata dump.json
See manage.py docs for more.
I've asked a similar question here and got quite a few answers.
There are quite a lot of ways of doing it, like manually doing the dumping and reloading with SQL, using fixtures or using one of the "emerging" schema-evolution packages for Django:
Django Evolution
South
dmigrations
(there's a DjangoCon video of a panel on schema-evolution in Django where these 3 solutions are discussed)
Depends on the scope of the changes. If it's beyond an ALTER, you're doing major surgery. Make backups of model as well as database so you can go back.
My preference is to put your new (revised, corrected, expanded) model in as a NEW application. It won't have URL's or anything, just a model.
Creating the new model as a new application. Create tests, just to be sure it works.
syncdb to build this interim implementation of the new model.
Write a little one-time utility to query your old model, and load your new model. You might want to try this in pure SQL. I prefer to write a simple query, build and save loop.
After the new model is loaded, you can dump this to a JSON file.
Once you've pulled the data out of your old model, you can rebuild your DB in the preferred new format.
Move the new model into your existing application.
Drop the old versions of the application's tables.
syncdb to build the new tables.
Load the JSON file with the data.
Django now has its own built-in migrations, documented at:
https://docs.djangoproject.com/en/dev/topics/migrations/
Look with manage.py sqlall what the parameters are for the new columns and manually add them in your database with Alter table statements. This way you don't have to redo your database; It requires some SQL knowledge though...
Take a look here (Scroll down to "Making Changes to a Database Schema")
Perform these steps in order may help you:
For more details,
clickhere: http://south.readthedocs.org/en/latest/
1) python manage.py schemamigration apps.appname --initial
Above step creates migration folder as default.
2) python manage.py migrate apps.appname --fake
generates a fake migration.
3) python manage.py schemamigration apps.appname --auto
Then you can add fields as you wish and perform the above command.
4) python manage.py migrate apps.appname
Then migrate the files to the database.