Django Migration difference between dev and test postgres databases - django

Question

I have a development database I was working on and I had issues with the migrations taking for adding a foreignkey field. I ended up having to blow away the database after clearing my migrations folder out and redoing it. So now I have one migration file...
The problem is, I pulled code to my test server, and now that database is VERY out of sync (it's not, django thinks it is. It really just needs a table added and a field). Though running make migrations breaks as the migration folder I had pushed was clear of all but one migration and does not jive with the migration folder on the test server.
Any ideas as to how I can reconcile this, it is my test data so blowing away the database here and starting new isn't an issue, but this will be a huge issue again when I push to production (and cannot blow away that database). Maybe dump the data/database using pg_dump, blow away the database, run migrations and load the data back via the dump file?
EDIT:
I did try to create my own migration manually since I was in a state where makemigrations said nothing new was done. My migration file:
The error it gives me (no idea what this is telling me)
Operations to perform:
Apply all migrations: filer, sessions, admin, auth, contenttypes, swsite, registration, easy_thumbnails
Running migrations:
Rendering model states... DONE
Applying swsite.0001_initial... OK
Applying swsite.0002_auto_20170302_0841...Traceback (most recent call last):
File "manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "/usr/lib64/python2.7/site-packages/django/core/management/__init__.py", line 353, in execute_from_command_line
utility.execute()
File "/usr/lib64/python2.7/site-packages/django/core/management/__init__.py", line 345, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/usr/lib64/python2.7/site-packages/django/core/management/base.py", line 348, in run_from_argv
self.execute(*args, **cmd_options)
File "/usr/lib64/python2.7/site-packages/django/core/management/base.py", line 399, in execute
output = self.handle(*args, **options)
File "/usr/lib64/python2.7/site-packages/django/core/management/commands/migrate.py", line 200, in handle
executor.migrate(targets, plan, fake=fake, fake_initial=fake_initial)
File "/usr/lib64/python2.7/site-packages/django/db/migrations/executor.py", line 92, in migrate
self._migrate_all_forwards(plan, full_plan, fake=fake, fake_initial=fake_initial)
File "/usr/lib64/python2.7/site-packages/django/db/migrations/executor.py", line 121, in _migrate_all_forwards
state = self.apply_migration(state, migration, fake=fake, fake_initial=fake_initial)
File "/usr/lib64/python2.7/site-packages/django/db/migrations/executor.py", line 198, in apply_migration
state = migration.apply(state, schema_editor)
File "/usr/lib64/python2.7/site-packages/django/db/migrations/migration.py", line 115, in apply
operation.state_forwards(self.app_label, project_state)
File "/usr/lib64/python2.7/site-packages/django/db/migrations/operations/fields.py", line 50, in state_forwards
state.models[app_label, self.model_name_lower].fields.append((self.name, field))
KeyError: (u'swsite', u'cesiumentity')
The migration:
# -*- coding: utf-8 -*-
# Generated by Django 1.9.6 on 2017-03-02 15:41
from __future__ import unicode_literals
from django.db import migrations, models
import django.contrib.gis.db.models.fields
import django.db.models.deletion
class Migration(migrations.Migration):
dependencies = [
('swsite', '0001_initial'),
]
operations = [
migrations.CreateModel(
name='ZoneEntity',
fields=[
('zone_number', models.CharField(max_length=100, primary_key=True, serialize=False)),
('mpoly', django.contrib.gis.db.models.fields.PolygonField(srid=4326)),
('created_at', models.DateField(auto_now_add=True)),
('updated_at', models.DateField(auto_now=True)),
],
),
migrations.AddField(
model_name='cesiumentity',
name='zone_id',
field=models.ForeignKey(blank=True, null=True, on_delete=django.db.models.deletion.CASCADE, to='swsite.ZoneEntity'),
),
]

Answer 1

If this is something you can do manually (add one field and one table), you can set the migrations as completed in the migration table (either all of them, or just the ones that are causing issues).

Answer 2

This might help you out:
https://www.algotech.solutions/blog/python/django-migrations-and-how-to-manage-conflicts/
As you are the single developer for the project, python manage.py migrate should be fine if you are pushing migrations in the git repo.
Or you can ignore migrations folder by adding it to .gitignore and run python manage.py makemigrations on test server every time db is modified and finally u can execute python manage.py migrate to reflect changes in the db.