"Django_content_type already exists" - after running migrate on server after database restore

Question

I've migrated across to a server environment, and finally got everything working. The django project is rendering properly, but there seems to be a big problem with the migrations/database.

When I try and run migrations, I'm getting this error, which is affecting other things (like scripts I use to populate the project)

 File "/home//.virtualenvs/versal/lib/python3.7/site-packages/djang                                              o/db/backends/utils.py", line 83, in _execute
    return self.cursor.execute(sql)
django.db.utils.ProgrammingError: relation "django_content_type" already exists

(versal) 06:18 ~/Versal/versal (master)$  Failing row contains (null, contenttypes, 0001_initial, 2019-04-29 06:11:02.087041+0

I tried to cleanup migrations and run them again, but this hasn't worked, as this is what 'showmigrations' shows.

accounts
 [ ] 0001_initial
admin
 [ ] 0001_initial
 [ ] 0002_logentry_remove_auto_add
 [ ] 0003_logentry_add_action_flag_choices
auth
 [ ] 0001_initial
 [ ] 0002_alter_permission_name_max_length
 [ ] 0003_alter_user_email_max_length
 [ ] 0004_alter_user_username_opts
 [ ] 0005_alter_user_last_login_null
 [ ] 0006_require_contenttypes_0002
 [ ] 0007_alter_validators_add_error_messages
 [ ] 0008_alter_user_username_max_length
 [ ] 0009_alter_user_last_name_max_length
blog
 [ ] 0001_initial
 [ ] 0002_auto_20190225_1221
 [ ] 0003_auto_20190225_1251
contenttypes
 [ ] 0001_initial
 [ ] 0002_remove_content_type_name
core
 [ ] 0001_initial
 [ ] 0002_auto_20190331_1730
 [ ] 0003_auto_20190404_0920
curate
 [ ] 0001_initial
 [ ] 0002_item_video
 [ ] 0003_set
 [ ] 0004_auto_20190424_1620
 [ ] 0005_item_tags
django_comments
 [ ] 0001_initial
 [ ] 0002_update_user_email_field_length
 [ ] 0003_add_submit_date_index
podcast
 [ ] 0001_initial
 [ ] 0002_remove_episode_order
 [ ] 0003_remove_show_ttl
 [ ] 0004_auto_20170917_0503
 [ ] 0005_episode_guid
 [ ] 0006_auto_20170920_1833
 [ ] 0007_auto_20170920_2212
 [ ] 0008_auto_20170920_2212
 [ ] 0009_auto_20170923_0129
 [ ] 0010_auto_20170923_0131
 [ ] 0011_episode_itunes_title
 [ ] 0012_episode_type
 [ ] 0013_episode_number
 [ ] 0014_episode_season
 [ ] 0015_show_type
 [ ] 0016_auto_20170923_2000
 [ ] 0017_auto_20170923_2133
 [ ] 0018_auto_20170924_0609
 [ ] 0019_auto_20170924_1839
 [ ] 0020_auto_20171026_2121
 [ ] 0021_auto_20171028_1742
 [ ] 0022_remove_category_json
 [ ] 0023_auto_20171121_2139
 [ ] 0024_show_ttl
 [ ] 0025_auto_20171211_0342
 [ ] 0026_auto_20171211_0342
 [ ] 0027_auto_20171211_0424
 [ ] 0028_auto_20171211_0424
 [ ] 0029_auto_20171211_0424
 [ ] 0030_auto_20190426_1051
sessions
 [ ] 0001_initial
sites
 [ ] 0001_initial
 [ ] 0002_alter_domain_unique
taggit
 [ ] 0001_initial
 [ ] 0002_auto_20150616_2121
 [ ] 0003_taggeditem_add_unique_index
threadedcomments
 [ ] 0001_initial
 [ ] 0002_auto_20150521_2011
 [ ] 0003_threadedcomment_newest_activity

I have those migrations on my local machine - I can add them back to where they out to be with a git push. But the problem persists.

My expected outcome is that I can makemigrations and migrate without errors each and every time...

If I run --fake-initial after make migrations, I get this:

django.db.utils.IntegrityError: null value in column "id" violates not-null constraint
DETAIL:  Failing row contains (null, contenttypes, 0001_initial, 2019-04-29 06:48:55.697347+00).

I should also say, that if I run the command makemigrations, I get 'No Changes Detected', so in that sense Django is relatively happy.

Answer 1

I solved this issue on Django 2.2.7 or Django 3.0 hosted on Ubuntu 18.04 + Postgres 10.10 version.

# Restore the database in Postgres database (used pgAdmin tool for this)

(virtualenv) python manage.py loaddata dumpfile.json

# Dropping django_migrations table from the database (used pgAdmin tool for this)

(virtualenv) python manage.py makemigrations
(virtualenv) python manage.py migrate --fake
(virtualenv) python manage.py migrate
(virtualenv) python manage.py collectstatic
(virtualenv) python manage.py runserver 0.0.0.0:8000

Cheers!