(vfoss_org_env) [dang@dai142 vfoss_org]$ pip check django-filer 1.2.5 has requirement django-polymorphic<0.9,>=0.7, but you have django-polymorphic 1.0.2. (vfoss_org_env) [dang@dai142 vfoss_org]$ pip install django-filer
./manage makemigrations ./manage migrate
Django has a handy management command that will give you the necessary SQL to drop all the tables for an app. See the sqlclear docs for more information. Basically, running ./manage.py sqlclear myappname you'll get the SQL statements that should be executed to get rid of all traces of the app in your DB. You still need to copy and paste (or pipe) those statements into your SQL client. Removed in Django 1.9
from django.contrib.contenttypes.models import ContentType
for c in ContentType.objects.all():
if not c.model_class():
print "deleting %s"%c
c.delete()
Excellent answer, just one addition that I'd make: pip uninstall package-name is your friend, much nicer than trawling around your PYTHONPATH. – Daveyjoe
On Django 1.7, if you use migration, step 1 will be ./manage.py migrate myappname zero. And it will automatically execute the SQL as well. – Nathan Do Dec 20 '14 at 8:03
In this post marinamele.com/how-to-correctly-remove-a-model-or-app-in-django explain hot wo delete models and apps in Django. It's great together with this answer. – bgarcial Jan 19 at 20:27
sqlclear was removed in Django 1.9 so this answer is only good for previous versions. See: docs.djangoproject.com/en/1.10/releases/1.9/… – Akhorus Nov 24 at 14:03
Enable localhost access:
nano /var/lib/pgsql/data/pg_hba.conf host all all ::1/128 md5 host all postgres 127.0.0.1/32 md5
Backup:
pg_dump -U some_user -Fc database_name > mydb.dump pg_dump database_name_here > database.bak pg_dump -Fc database_name_here > database.bak # compressed binary format pg_dump -Ft database_name_here > database.tar # tarball pg_dump -h 127.0.0.1 -U vfossdbuser -Fc vfosstestdb > vfosstestdb_201612082015.dump Password: vfossdbuser
Restore:
pg_restore -U some_user -d database_name mydb.dump pg_restore -h 127.0.0.1 -U vfossdbuser -Fc -C vfosstestdb_201612082015.dump
If your database already exists you only need to run the following:
pg_restore -Fc database.bak # restore compressed binary format pg_restore -Ft database.tar # restore tarball
However, if you're creating your database new from the restore you'll want to run a command similar to the following:
pg_restore -Fc -C database.bak # restore compressed binary format pg_restore -Ft -C database.tar # restore tarball
To dump a database called mydb into a SQL-script file:
$ pg_dump mydb > db.sql
To reload such a script into a (freshly created) database named newdb:
$ psql -d newdb -f db.sql
To dump a database into a custom-format archive file:
$ pg_dump -Fc mydb > db.dump
To dump a database into a directory-format archive:
$ pg_dump -Fd mydb -f dumpdir
To dump a database into a directory-format archive in parallel with 5 worker jobs:
$ pg_dump -Fd mydb -j 5 -f dumpdir
To reload an archive file into a (freshly created) database named newdb:
$ pg_restore -d newdb db.dump
To dump a single table named mytab:
$ pg_dump -t mytab mydb > db.sql
To dump all tables whose names start with emp in the detroit schema, except for the table named employee_log:
$ pg_dump -t 'detroit.emp*' -T detroit.employee_log mydb > db.sql
To dump all schemas whose names start with east or west and end in gsm, excluding any schemas whose names contain the word test:
$ pg_dump -n 'east*gsm' -n 'west*gsm' -N '*test*' mydb > db.sql
The same, using regular expression notation to consolidate the switches:
$ pg_dump -n '(east|west)*gsm' -N '*test*' mydb > db.sql
To dump all database objects except for tables whose names begin with ts_:
$ pg_dump -T 'ts_*' mydb > db.sql
To specify an upper-case or mixed-case name in -t and related switches, you need to double-quote the name; else it will be folded to lower case (see Patterns). But double quotes are special to the shell, so in turn they must be quoted. Thus, to dump a single table with a mixed-case name, you need something like
$ pg_dump -t "\"MixedCaseName\"" mydb > mytab.sql
Some new package use 'migrations' folder for migration now (default from django 1.8)
django.db.migrations.exceptions.NodeNotFoundError: Migration djangocms_blog.0004_auto_20150108_1435 dependencies reference nonexistent parent node (u'cmsplugin_filer_image', u'0003_mv_thumbnail_option_to_filer_20160119_1720')
Fix: goto settings.py 202 MIGRATION_MODULES, comment the module out:
203 ## django 1.8.2 204 'cmsplugin_filer_image': 'cmsplugin_filer_image.migrations_django',
url is now built-in, just remove the line.
[dang@dai142 vfoss_org]$ grep -ri "url from future" .
[dang@dai142 vfoss_org]$ find ./static/ -type f -exec sed -i 's/{% load url from future %}//g' {} +
[dang@dai142 vfoss_org]$ find ./themes/ -type f -exec sed -i 's/{% load url from future %}//g' {} +
:-)
Steps: