I wanted to validate if there is a bug in makemigrations in django 1.8 with sql lite or I am doing something wrong.
After I Dropped my DB and deleted all migration folders. I run
python manage.py makemigrations
python manage.py migrate
DB gets created no problems.
2.I have to modify existing model in one of the apps (app abc)
I perform my change and run again
python manage.py makemigrations
3.it doesn't find any changes
then I run same thing again but with app name
python manage.py makemigrations abc
4.It does some updates in migrations , I believe it recreates all the tables and not just my change !!!!
5.Then I execute
python manage.py migrate
and getting error that table already exists .
Is it a bug in django framework or I am doing something wrong and there is a reason why it behaves this way?
Copy paste from my shell starting from step 2:
(mrp) C:\Users\I812624\dev\mrp\src>python manage.py makemigrations
No changes detected
(mrp) C:\Users\I812624\dev\mrp\src>python manage.py makemigrations purchase
Migrations for 'purchase':
0001_initial.py:
- Create model PO
- Create model POmaterial
(mrp) C:\Users\I812624\dev\mrp\src>python manage.py migrate
Operations to perform:
Synchronize unmigrated apps: customer, manufacture, product, django_filters, a
utofixture, staticfiles, messages, smart_selects, watson, sales, item, django_co
untries, mptt, inventory, django_select2, production, main, crispy_forms
Apply all migrations: purchase, vendor, sessions, admin, sites, flatpages, con
tenttypes, auth, registration
Synchronizing apps without migrations:
Creating tables...
Running deferred SQL...
Installing custom SQL...
Running migrations:
Rendering model states... DONE
Applying purchase.0001_initial...Traceback (most recent call last):
File "manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "C:\Users\I812624\dev\mrp\lib\site-packages\django\core\management\__init
__.py", line 338, in execute_from_command_line
utility.execute()
File "C:\Users\I812624\dev\mrp\lib\site-packages\django\core\management\__init
__.py", line 330, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "C:\Users\I812624\dev\mrp\lib\site-packages\django\core\management\base.p
y", line 390, in run_from_argv
self.execute(*args, **cmd_options)
File "C:\Users\I812624\dev\mrp\lib\site-packages\django\core\management\base.p
y", line 441, in execute
output = self.handle(*args, **options)
File "C:\Users\I812624\dev\mrp\lib\site-packages\django\core\management\comman
ds\migrate.py", line 221, in handle
executor.migrate(targets, plan, fake=fake, fake_initial=fake_initial)
File "C:\Users\I812624\dev\mrp\lib\site-packages\django\db\migrations\executor
.py", line 110, in migrate
self.apply_migration(states[migration], migration, fake=fake, fake_initial=f
ake_initial)
File "C:\Users\I812624\dev\mrp\lib\site-packages\django\db\migrations\executor
.py", line 147, in apply_migration
state = migration.apply(state, schema_editor)
File "C:\Users\I812624\dev\mrp\lib\site-packages\django\db\migrations\migratio
n.py", line 115, in apply
operation.database_forwards(self.app_label, schema_editor, old_state, projec
t_state)
File "C:\Users\I812624\dev\mrp\lib\site-packages\django\db\migrations\operatio
ns\models.py", line 59, in database_forwards
schema_editor.create_model(model)
File "C:\Users\I812624\dev\mrp\lib\site-packages\django\db\backends\base\schem
a.py", line 282, in create_model
self.execute(sql, params or None)
File "C:\Users\I812624\dev\mrp\lib\site-packages\django\db\backends\base\schem
a.py", line 107, in execute
cursor.execute(sql, params)
File "C:\Users\I812624\dev\mrp\lib\site-packages\django\db\backends\utils.py",
line 79, in execute
return super(CursorDebugWrapper, self).execute(sql, params)
File "C:\Users\I812624\dev\mrp\lib\site-packages\django\db\backends\utils.py",
line 64, in execute
return self.cursor.execute(sql, params)
File "C:\Users\I812624\dev\mrp\lib\site-packages\django\db\utils.py", line 97,
in __exit__
six.reraise(dj_exc_type, dj_exc_value, traceback)
File "C:\Users\I812624\dev\mrp\lib\site-packages\django\db\backends\utils.py",
line 62, in execute
return self.cursor.execute(sql)
File "C:\Users\I812624\dev\mrp\lib\site-packages\django\db\backends\sqlite3\ba
se.py", line 316, in execute
return Database.Cursor.execute(self, query)
django.db.utils.OperationalError: table "purchase_po" already exists
To answer my own question .
So what I have figured out . I believe the problem is that I have originally deleted the folders migrations and when I run makemigrations without specifying particular app it does create a DB but it dosent create the folder makemigrations with ____init____.py inside it.
solution each time when you drop db and delete migrations folder for whatever reason dont just delete the migrations folder but only its content excluding init file.
Or when you do delete the folder run make migrations individually for each app as #MicroPyramid suggested.
Without doing deeper investigation it looks to me or as confusing designed behaviour or a bug from Django side.
Related
I have tried using ./manage.py migrate app_name zero command which was proposed but i keep on getting errors after i run python manage.py migrate testapp. My last solution would be to go to mysql drop entire db
Operations to perform:
Apply all migrations: testapp
Running migrations:
Rendering model states... DONE
Applying testapp.0001_initial...Traceback (most recent call last):
File "manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "C:\Python27\lib\site-packages\django-1.9.7-py2.7.egg\django\core\management\__init__.py", line 353,
_line
utility.execute()
File "C:\Python27\lib\site-packages\django-1.9.7-py2.7.egg\django\core\management\__init__.py", line 345,
self.fetch_command(subcommand).run_from_argv(self.argv)
File "C:\Python27\lib\site-packages\django-1.9.7-py2.7.egg\django\core\management\base.py", line 348, in
self.execute(*args, **cmd_options)
File "C:\Python27\lib\site-packages\django-1.9.7-py2.7.egg\django\core\management\base.py", line 399, in
output = self.handle(*args, **options)
File "C:\Python27\lib\site-packages\django-1.9.7-py2.7.egg\django\core\management\commands\migrate.py", l
executor.migrate(targets, plan, fake=fake, fake_initial=fake_initial)
File "C:\Python27\lib\site-packages\django-1.9.7-py2.7.egg\django\db\migrations\executor.py", line 92, in
self._migrate_all_forwards(plan, full_plan, fake=fake, fake_initial=fake_initial)
File "C:\Python27\lib\site-packages\django-1.9.7-py2.7.egg\django\db\migrations\executor.py", line 121, i
state = self.apply_migration(state, migration, fake=fake, fake_initial=fake_initial)
File "C:\Python27\lib\site-packages\django-1.9.7-py2.7.egg\django\db\migrations\executor.py", line 198, i
state = migration.apply(state, schema_editor)
File "C:\Python27\lib\site-packages\django-1.9.7-py2.7.egg\django\db\migrations\migration.py", line 123,
operation.database_forwards(self.app_label, schema_editor, old_state, project_state)
File "C:\Python27\lib\site-packages\django-1.9.7-py2.7.egg\django\db\migrations\operations\models.py", li
rds
schema_editor.create_model(model)
File "C:\Python27\lib\site-packages\django-1.9.7-py2.7.egg\django\db\backends\base\schema.py", line 284,
self.execute(sql, params or None)
File "C:\Python27\lib\site-packages\django-1.9.7-py2.7.egg\django\db\backends\base\schema.py", line 110,
cursor.execute(sql, params)
File "C:\Python27\lib\site-packages\django-1.9.7-py2.7.egg\django\db\backends\utils.py", line 79, in exec
return super(CursorDebugWrapper, self).execute(sql, params)
File "C:\Python27\lib\site-packages\django-1.9.7-py2.7.egg\django\db\backends\utils.py", line 64, in exec
return self.cursor.execute(sql, params)
File "C:\Python27\lib\site-packages\django-1.9.7-py2.7.egg\django\db\utils.py", line 95, in __exit__
six.reraise(dj_exc_type, dj_exc_value, traceback)
File "C:\Python27\lib\site-packages\django-1.9.7-py2.7.egg\django\db\backends\utils.py", line 62, in exec
return self.cursor.execute(sql)
File "C:\Python27\lib\site-packages\django-1.9.7-py2.7.egg\django\db\backends\mysql\base.py", line 112, i
return self.cursor.execute(query, args)
File "C:\Python27\lib\site-packages\MySQLdb\cursors.py", line 174, in execute
self.errorhandler(self, exc, value)
File "C:\Python27\lib\site-packages\MySQLdb\connections.py", line 36, in defaulterrorhandler
raise errorclass, errorvalue
django.db.utils.OperationalError: (1050, "Table 'testapp_cinfo' already exists")
You are applying an initial migration, which means that you are creating the first version of that app’s tables.
But you already have that table in the database so you can fake the initial migration
python manage.py migrate --fake-initial
The --fake-initial flag to migrate was added in Django 1.8. Previously, Django would always automatically fake-apply initial migrations if it detected that the tables exist.
But note that this only works given two things:
You have not changed your models since you made their tables (which you have).
You have not manually edited your database.
So you can't fake them either.
I Want to use the current database
If you have your previous unaltered version of initial migration files of the testapp with migration(non-initial) files with your changes, you can use them for migration.
First fake that initial migration and then apply your changes
(This may be tricky now, as you also have to truncate django_migrations table that stores migrations data)
I can start from scratch -
No Problem (drop your database) as its an initial migration and that's what they are for - Create DB/Table.
If you already have tables in your db, try ./manage.py flush to clear all data. Flush carries out the SQL Drops on the entire db.
If you want to delete the db, drop the mysql db. Create another mysql db with the same name. Then run ./manage.py makemigrations followed by ./manage.py migrate to recreate the tables in the db.
I did my django dev on SQlite and now I am trying to run my apps with postgres 9.5.
However when I run migrate I am getting this error
django.db.utils.ProgrammingError: relation "django_content_type" does not exist
. I am using django 1.8 and python 2.7 and getting it when doing migration , when running -fake initial getting same error.
I am looking at existing answers (this problem is common) but I dont see clear answer that works for me.
> (mrp) C:\Users\I812624\dev\mrp\src>python manage.py migrate
Operations to perform:
Synchronize unmigrated apps: django_filters, autofixture, staticfiles, message
s, smart_selects, watson, django_select2, django_countries, mptt, psycopg2, main
, crispy_forms
Apply all migrations: customer, manufacture, product, vendor, purchase, admin,
sessions, sales, flatpages, sites, item, contenttypes, production, auth, regist
ration, inventory
Synchronizing apps without migrations:
Creating tables...
Creating table watson_searchentry
Running deferred SQL...
Traceback (most recent call last):
File "manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "C:\Users\I812624\dev\mrp\lib\site-packages\django\core\management\__init
__.py", line 338, in execute_from_command_line
utility.execute()
File "C:\Users\I812624\dev\mrp\lib\site-packages\django\core\management\__init
__.py", line 330, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "C:\Users\I812624\dev\mrp\lib\site-packages\django\core\management\base.p
y", line 390, in run_from_argv
self.execute(*args, **cmd_options)
File "C:\Users\I812624\dev\mrp\lib\site-packages\django\core\management\base.p
y", line 441, in execute
output = self.handle(*args, **options)
File "C:\Users\I812624\dev\mrp\lib\site-packages\django\core\management\comman
ds\migrate.py", line 179, in handle
created_models = self.sync_apps(connection, executor.loader.unmigrated_apps)
File "C:\Users\I812624\dev\mrp\lib\site-packages\django\core\management\comman
ds\migrate.py", line 317, in sync_apps
cursor.execute(statement)
File "C:\Users\I812624\dev\mrp\lib\site-packages\django\db\backends\utils.py",
line 79, in execute
return super(CursorDebugWrapper, self).execute(sql, params)
File "C:\Users\I812624\dev\mrp\lib\site-packages\django\db\backends\utils.py",
line 64, in execute
return self.cursor.execute(sql, params)
File "C:\Users\I812624\dev\mrp\lib\site-packages\django\db\utils.py", line 97,
in __exit__
six.reraise(dj_exc_type, dj_exc_value, traceback)
File "C:\Users\I812624\dev\mrp\lib\site-packages\django\db\backends\utils.py",
line 62, in execute
return self.cursor.execute(sql)
django.db.utils.ProgrammingError: relation "django_content_type" does not exist
Your DATABASES section in settings.py should be like:
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.postgresql_psycopg2',
'NAME': 'yourdb',
'USER': 'youruser',
'PASSWORD': 'yourpass',
'HOST': '',
},
}
Your INSTALLED_APPS should include psycopg2
Once this in place and server restarted, you can remigrate, which should create the missing table
django_content_type should be created automatically.
I'm wondering how did you do your makemigrations
Maybe try
python manage.py makemigrations
instead of doing them one by one
So after playing around it started to work.
Solution was that I havent added the server to pgAdmin https://www.pgadmin.org/
I was under assumptions that pgadmin is just a tool to see whats going on but without adding postgre to pgadmin the migration had errors.
When running
python3 manage.py migrate
I was asked what the default value of 'id' should be and entered 1. I had read
https://docs.djangoproject.com/en/1.9/howto/writing-migrations/#migrations-that-add-unique-fields
but that was a bit too complicated for me so tried 1.
Now when I run
python3 manage.py migrate
I get the following error:
vagrant#vagrant-ubuntu-trusty-64:/vagrant/grader$ python3 manage.py migrate
Operations to perform:
Apply all migrations: admin, core, contenttypes, auth, sessions
Running migrations:
Rendering model states... DONE
Applying core.0002_auto_20160103_1302...Traceback (most recent call last):
File "/usr/local/lib/python3.4/dist-packages/django/db/backends/utils.py", line 64, in execute
return self.cursor.execute(sql, params)
psycopg2.ProgrammingError: multiple default values specified for column "id" of table "core_student"
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "/usr/local/lib/python3.4/dist-packages/django/core/management/__init__.py", line 350, in execute_from_command_line
utility.execute()
File "/usr/local/lib/python3.4/dist-packages/django/core/management/__init__.py", line 342, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/usr/local/lib/python3.4/dist-packages/django/core/management/base.py", line 348, in run_from_argv
self.execute(*args, **cmd_options)
File "/usr/local/lib/python3.4/dist-packages/django/core/management/base.py", line 399, in execute
output = self.handle(*args, **options)
File "/usr/local/lib/python3.4/dist-packages/django/core/management/commands/migrate.py", line 200, in handle
executor.migrate(targets, plan, fake=fake, fake_initial=fake_initial)
File "/usr/local/lib/python3.4/dist-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/local/lib/python3.4/dist-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/local/lib/python3.4/dist-packages/django/db/migrations/executor.py", line 198, in apply_migration
state = migration.apply(state, schema_editor)
File "/usr/local/lib/python3.4/dist-packages/django/db/migrations/migration.py", line 123, in apply
operation.database_forwards(self.app_label, schema_editor, old_state, project_state)
File "/usr/local/lib/python3.4/dist-packages/django/db/migrations/operations/fields.py", line 62, in database_forwards
field,
File "/usr/local/lib/python3.4/dist-packages/django/db/backends/base/schema.py", line 396, in add_field
self.execute(sql, params)
File "/usr/local/lib/python3.4/dist-packages/django/db/backends/base/schema.py", line 110, in execute
cursor.execute(sql, params)
File "/usr/local/lib/python3.4/dist-packages/django/db/backends/utils.py", line 79, in execute
return super(CursorDebugWrapper, self).execute(sql, params)
File "/usr/local/lib/python3.4/dist-packages/django/db/backends/utils.py", line 64, in execute
return self.cursor.execute(sql, params)
File "/usr/local/lib/python3.4/dist-packages/django/db/utils.py", line 95, in __exit__
six.reraise(dj_exc_type, dj_exc_value, traceback)
File "/usr/local/lib/python3.4/dist-packages/django/utils/six.py", line 685, in reraise
raise value.with_traceback(tb)
File "/usr/local/lib/python3.4/dist-packages/django/db/backends/utils.py", line 64, in execute
return self.cursor.execute(sql, params)
django.db.utils.ProgrammingError: multiple default values specified for column "id" of table "core_student"
How can I recover from this failed migration? I went into the psql command promt and typed
SELECT * FROM core_students
It returned 0 rows so I don'w know why I have a problem.
Shouldn't Django automatically make the 'id' field be unique numbers?
EDIT:
The id has been auto generated by the Django migration.
student model:
class Student(models.Model):
created = models.DateTimeField(auto_now_add=True)
updated = models.DateTimeField(auto_now=True)
owner = models.ForeignKey('auth.User', related_name='students')
identity_number = models.CharField(max_length=50)
first_name = models.CharField(max_length=50)
last_name = models.CharField(max_length=50)
I often run into a similar problem where a migration fails for whatever reason, and only part of it gets applied to the database.
In theory you should be able to go into the database and run queries to finish the migration, but knowing what exact queries to run and what parts of the migration haven't been run is difficult in my experience.
The most dependable way I've found to fix it is to fake the migration, then back up the model, comment it out in models.py, then make a migration to delete it, then fake that as well. Then I can go into the database, drop the table, and then make a new migration to recreate it the way I now want to be.
Here are the commands I run:
python manage.py migrate --fake [appname] #fake the failed migration
#comment out the model in models.py and back up the data
python manage.py makemigrations [appname]
python manage.py migrate --fake [appname] #fake the migration to delete
the table
python manage.py dbshell
#drop the table. Mysql would be: DROP TABLE [appname]_[modelname];
#exit dbshell
#Uncomment the model in models.py adding in whatever changes were originally wanted
python manage.py makemigrations [appname]
python manage.py migrate #assuming your model change is valid, this should work this time.
#reload your data into the table
No, it's not elegant, but it gets django migrations working again without having to guess how far django got through a migration before it failed.
I have a project running on django 1.6 and working to upgrade it to 1.8 which includes moving from south migration to django's migration.
I tried to follow steps mentioned by django documentation on how to update from south to django migrations here https://docs.djangoproject.com/en/1.8/topics/migrations/#upgrading-from-south
& am facing a problem when trying to migrate --initial-fake, it seems like even though some tables exists django migration is trying to create them
./manage.py migrate --fake-initial
Running migrations:
Rendering model states... DONE
Applying retail.0001_initial... FAKED
Applying contenttypes.0001_initial... FAKED
Applying contenttypes.0002_remove_content_type_name... OK
Applying auth.0001_initial... FAKED
Applying auth.0002_alter_permission_name_max_length... OK
Applying auth.0003_alter_user_email_max_length... OK
Applying auth.0004_alter_user_username_opts... OK
Applying auth.0005_alter_user_last_login_null... OK
Applying auth.0006_require_contenttypes_0002... OK
Applying account.0001_initial... FAKED
Applying default.0001_initial...Traceback (most recent call last):
File "./manage.py", line 11, in <module>
execute_from_command_line(sys.argv)
File "/project-path/lib/python2.7/site-packages/django/core/management/__init__.py", line 338, in execute_from_command_line
utility.execute()
File "/project-path/lib/python2.7/site-packages/django/core/management/__init__.py", line 330, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/project-path/lib/python2.7/site-packages/django/core/management/base.py", line 393, in run_from_argv
self.execute(*args, **cmd_options)
File "/project-path/lib/python2.7/site-packages/django/core/management/base.py", line 444, in execute
output = self.handle(*args, **options)
File "/project-path/lib/python2.7/site-packages/django/core/management/commands/migrate.py", line 222, in handle
executor.migrate(targets, plan, fake=fake, fake_initial=fake_initial)
File "/project-path/lib/python2.7/site-packages/django/db/migrations/executor.py", line 110, in migrate
self.apply_migration(states[migration], migration, fake=fake, fake_initial=fake_initial)
File "/project-path/lib/python2.7/site-packages/django/db/migrations/executor.py", line 148, in apply_migration
state = migration.apply(state, schema_editor)
File "/project-path/lib/python2.7/site-packages/django/db/migrations/migration.py", line 115, in apply
operation.database_forwards(self.app_label, schema_editor, old_state, project_state)
File "/project-path/lib/python2.7/site-packages/django/db/migrations/operations/models.py", line 59, in database_forwards
schema_editor.create_model(model)
File "/project-path/lib/python2.7/site-packages/django/db/backends/base/schema.py", line 286, in create_model
self.execute(sql, params or None)
File "/project-path/lib/python2.7/site-packages/django/db/backends/base/schema.py", line 111, in execute
cursor.execute(sql, params)
File "/project-path/lib/python2.7/site-packages/django/db/backends/utils.py", line 79, in execute
return super(CursorDebugWrapper, self).execute(sql, params)
File "/project-path/lib/python2.7/site-packages/django/db/backends/utils.py", line 64, in execute
return self.cursor.execute(sql, params)
File "/project-path/lib/python2.7/site-packages/django/db/utils.py", line 97, in __exit__
six.reraise(dj_exc_type, dj_exc_value, traceback)
File "/project-path/lib/python2.7/site-packages/django/db/backends/utils.py", line 62, in execute
return self.cursor.execute(sql)
django.db.utils.ProgrammingError: relation "social_auth_association" already exists
Any advise please?
regards,
Type python manage.py migrate --help
--fake Mark migrations as run without actually running them.
--fake-initial Detect if tables already exist and fake-apply initial
migrations if so. Make sure that the current database
schema matches your initial migration before using
this flag. Django will only check for an existing
table name.
From the documentation:
The only complication is if you have a circular dependency loop of foreign keys; in this case, makemigrations might make more than one initial migration, and you’ll need to mark them all as applied using:
python manage.py migrate --fake yourappnamehere
So try to run
python manage.py migrate --fake default
And it should do the trick.
I am trying to add south to my project on Heroku. I followed the following steps.
heroku run easy_install South
Added 'south' in INSTALLED_APPS in settings.py
Then
heroku run ./manage.py syncdb
heroku run ./manage.py convert_to_south sheets
Traceback
Running `./manage.py convert_to_south sheets` attached to terminal... up, run.2005
Creating migrations directory at '/app/sheets/migrations'...
Creating __init__.py in '/app/sheets/migrations'...
+ Added model sheets.Sheets
+ Added model sheets.UserSheets
+ Added M2M table for users on sheets.UserSheets
+ Added model sheets.SheetScribble
+ Added model sheets.SheetScribbleComment
+ Added model sheets.Tasks
+ Added model sheets.TaskComment
Created 0001_initial.py. You can now apply this migration with: ./manage.py migrate sheets
- Soft matched migration 0001 to 0001_initial.
Running migrations for sheets:
- Nothing to migrate.
- Loading initial data for sheets.
Installed 0 object(s) from 0 fixture(s)
App 'sheets' converted. Note that South assumed the application's models matched the database
(i.e. you haven't changed it since last syncdb); if you have, you should delete the sheets/migrations
directory, revert models.py so it matches the database, and try again.
then when I try to convert my second app to south,
heroku run ./manage.py convert_to_south scribbler
I get this error
Running `./manage.py convert_to_south scribbler` attached to terminal... up, run.6046
Creating migrations directory at '/app/scribbler/migrations'...
Creating __init__.py in '/app/scribbler/migrations'...
+ Added model scribbler.ScribbleMedia
+ Added model scribbler.Scribble
+ Added model scribbler.Tag
+ Added M2M table for scribbles on scribbler.Tag
+ Added model scribbler.SharedScribble
+ Added M2M table for users_favored on scribbler.SharedScribble
+ Added model scribbler.ScribbleComment
+ Added model scribbler.Connections
+ Added unique constraint for ['following', 'followers'] on scribbler.Connections
+ Added model scribbler.UserProfile
+ Added model scribbler.Invitation
+ Added model scribbler.Notifications
Created 0001_initial.py. You can now apply this migration with: ./manage.py migrate scribbler
Traceback (most recent call last):
File "./manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "/app/.heroku/venv/lib/python2.7/site-packages/django/core/management/__init__.py", line 443, in execute_from_command_line
utility.execute()
File "/app/.heroku/venv/lib/python2.7/site-packages/django/core/management/__init__.py", line 382, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/app/.heroku/venv/lib/python2.7/site-packages/django/core/management/base.py", line 196, in run_from_argv
self.execute(*args, **options.__dict__)
File "/app/.heroku/venv/lib/python2.7/site-packages/django/core/management/base.py", line 232, in execute
output = self.handle(*args, **options)
File "/app/.heroku/venv/lib/python2.7/site-packages/south/management/commands/convert_to_south.py", line 87, in handle
delete_ghosts=options.get("delete_ghosts", False),
File "/app/.heroku/venv/lib/python2.7/site-packages/django/core/management/__init__.py", line 150, in call_command
return klass.execute(*args, **defaults)
File "/app/.heroku/venv/lib/python2.7/site-packages/django/core/management/base.py", line 232, in execute
output = self.handle(*args, **options)
File "/app/.heroku/venv/lib/python2.7/site-packages/south/management/commands/migrate.py", line 108, in handle
ignore_ghosts = ignore_ghosts,
File "/app/.heroku/venv/lib/python2.7/site-packages/south/migration/__init__.py", line 193, in migrate_app
applied_all = check_migration_histories(applied_all, delete_ghosts, ignore_ghosts)
File "/app/.heroku/venv/lib/python2.7/site-packages/south/migration/__init__.py", line 74, in check_migration_histories
m = h.get_migration()
File "/app/.heroku/venv/lib/python2.7/site-packages/south/models.py", line 34, in get_migration
return self.get_migrations().migration(self.migration)
File "/app/.heroku/venv/lib/python2.7/site-packages/south/models.py", line 31, in get_migrations
return Migrations(self.app_name)
File "/app/.heroku/venv/lib/python2.7/site-packages/south/migration/base.py", line 61, in __call__
self.instances[app_label] = super(MigrationsMetaclass, self).__call__(app_label_to_app_module(app_label), **kwds)
File "/app/.heroku/venv/lib/python2.7/site-packages/south/migration/base.py", line 89, in __init__
self.set_application(application, force_creation, verbose_creation)
File "/app/.heroku/venv/lib/python2.7/site-packages/south/migration/base.py", line 161, in set_application
raise exceptions.NoMigrations(application)
south.exceptions.NoMigrations: Application '<module 'sheets' from '/app/sheets/__init__.py'>' has no migrations.
I am not sure what the problem is.
You shouldn't be running those commands ON heroku. You should be doing that on your local environment, pushing them to heroku, then running the migrate commands.
It has an "ephemeral filesystem" which probably cleared between those two commands. So south has a record of a 0001 migration, but it doesn't exist.
I'm not sure why it's being thrown during the "convert_to_south" command (some new south feature?), but that's my best guess.
Try doing it locally, committing the migration files, then proceeding to run the migrate commands on heroku.