on migrate command: ProgrammingError: column "district_id" of relation "data_entry" already exists

[jonathan.strong@…]

Got this error when I tried to run the initial makemigrations command for a project. I had been using South and was following documentation for upgrading to 1.7. Not sure what is happening. I noticed that prior to this error occurring some other index_together requirements had been accomplished successfully. Also it was on its 3rd migrations file for the app ... 001_initial and 002_auto had run successfully. I don't see any way to figure out which line in my models.py this was referencing.

Traceback (most recent call last):
  File "C:\Sites\votecruncher\manage.py", line 10, in <module>
    execute_from_command_line(sys.argv)
  File "C:\Python\lib\site-packages\django\core\management\__init__.py", line 385, in execute_from_command_line
    utility.execute()
  File "C:\Python\lib\site-packages\django\core\management\__init__.py", line 377, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "C:\Python\lib\site-packages\django\core\management\base.py", line 288, in run_from_argv
    self.execute(*args, **options.__dict__)
  File "C:\Python\lib\site-packages\django\core\management\base.py", line 337, in execute
    output = self.handle(*args, **options)
  File "C:\Python\lib\site-packages\django\core\management\commands\makemigrations.py", line 115, in handle
    self.write_migration_files(changes)
  File "C:\Python\lib\site-packages\django\core\management\commands\makemigrations.py", line 131, in write_migration_files
    self.stdout.write("    - %s\n" % operation.describe())
  File "C:\Python\lib\site-packages\django\db\migrations\operations\models.py",
line 291, in describe
    return "Alter %s for %s (%s constraints)" % (self.self.option_name, self.name, len(self.index_together))
AttributeError: 'AlterIndexTogether' object has no attribute 'self'

[Baptiste Mispelon]

Hi,

This looks like a duplicated of #22917 which was fixed in 70576740b0bb5289873f5a9a9a4e1a26b2c330e5.

Can you check if using the latest 1.7.x branch fixes the issue?

Thanks.

[jonathan.strong@…]

ok. now using stable/1.7.x ... it created the migrations sucessfully. When I went to run migrate, I got the following error:

Operations to perform:
  Synchronize unmigrated apps: ckeditor, json_field, debug_toolbar, django_exten
sions, bills, crispy_forms
  Apply all migrations: taggit, sessions, admin, sites, auth, blog, rollcalls, c
ontenttypes, members, main, data, geographies
Synchronizing apps without migrations:
  Creating tables...
  Installing custom SQL...
  Installing indexes...
Running migrations:
  Applying contenttypes.0001_initial... FAKED
  Applying auth.0001_initial... FAKED
  Applying admin.0001_initial... FAKED
  Applying blog.0001_initial... FAKED
  Applying members.0001_initial... FAKED
  Applying rollcalls.0001_initial... FAKED
  Applying geographies.0001_initial... FAKED
  Applying geographies.0002_auto_20140713_1302... FAKED
  Applying members.0002_auto_20140713_1302... FAKED
  Applying rollcalls.0002_auto_20140713_1302... FAKED
  Applying data.0001_initial... FAKED
  Applying data.0002_entry_district...Traceback (most recent call last):
  File "C:\Sites\votecruncher\manage.py", line 10, in <module>
    execute_from_command_line(sys.argv)
  File "C:\Python\lib\site-packages\django-1.7c1-py2.7.egg\django\core\management\__init__.py", line 385, in execute_from_command_line
    utility.execute()
  File "C:\Python\lib\site-packages\django-1.7c1-py2.7.egg\django\core\management\__init__.py", line 377, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "C:\Python\lib\site-packages\django-1.7c1-py2.7.egg\django\core\management\base.py", line 288, in run_from_argv
    self.execute(*args, **options.__dict__)
  File "C:\Python\lib\site-packages\django-1.7c1-py2.7.egg\django\core\management\base.py", line 337, in execute
    output = self.handle(*args, **options)
  File "C:\Python\lib\site-packages\django-1.7c1-py2.7.egg\django\core\management\commands\migrate.py", line 160, in handle
    executor.migrate(targets, plan, fake=options.get("fake", False))
  File "C:\Python\lib\site-packages\django-1.7c1-py2.7.egg\django\db\migrations\executor.py", line 62, in migrate
    self.apply_migration(migration, fake=fake)
  File "C:\Python\lib\site-packages\django-1.7c1-py2.7.egg\django\db\migrations\executor.py", line 96, in apply_migration
    migration.apply(project_state, schema_editor)
  File "C:\Python\lib\site-packages\django-1.7c1-py2.7.egg\django\db\migrations\migration.py", line 107, in apply
    operation.database_forwards(self.app_label, schema_editor, project_state, new_state)
  File "C:\Python\lib\site-packages\django-1.7c1-py2.7.egg\django\db\migrations\
operations\fields.py", line 37, in database_forwards
    field,
  File "C:\Python\lib\site-packages\django-1.7c1-py2.7.egg\django\db\backends\schema.py", line 409, in add_field
    self.execute(sql, params)
  File "C:\Python\lib\site-packages\django-1.7c1-py2.7.egg\django\db\backends\schema.py", line 98, in execute
    cursor.execute(sql, params)
  File "C:\Python\lib\site-packages\django-1.7c1-py2.7.egg\django\db\backends\utils.py", line 81, in execute
    return super(CursorDebugWrapper, self).execute(sql, params)
  File "C:\Python\lib\site-packages\django-1.7c1-py2.7.egg\django\db\backends\utils.py", line 65, in execute
    return self.cursor.execute(sql, params)
  File "C:\Python\lib\site-packages\django-1.7c1-py2.7.egg\django\db\utils.py",
line 94, in __exit__
    six.reraise(dj_exc_type, dj_exc_value, traceback)
  File "C:\Python\lib\site-packages\django-1.7c1-py2.7.egg\django\db\backends\utils.py", line 65, in execute
    return self.cursor.execute(sql, params)
django.db.utils.ProgrammingError: column "district_id" of relation "data_entry"
already exists

The model/field in question:

class Entry(models.Model):
  #... other fields
  district = models.ForeignKey('geographies.District', null=True, blank=True)

The foreign key is to a model in another app, geographies . Happy to provide additional detail if needed.

The intended behavior is for django to understand that these migrations need to be faked - yes? So I can just fake them manually and move on?

[Tim Graham]

Yes, I believe that's the proper solution ​as documented. If there's more to it, then please reopen or create a new ticket.