django - ValueError: Dependency on app with no migrations - django

I'm deploying my Django project to a VPS using Dokku. My project uses a CustomUser model, and there are two apps in the project: accounts which has the CustomUser and gradebook.
During deployment the process runs makemigrations and migrate. After deployment when I run python manage.py showmigrations I get the following:
account
[X] 0001_initial
[X] 0002_email_max_length
accounts
(no migrations)
admin
[X] 0001_initial
[X] 0002_logentry_remove_auto_add
[X] 0003_logentry_add_action_flag_choices
auth
[X] 0001_initial
[X] 0002_alter_permission_name_max_length
[X] 0003_alter_user_email_max_length
[X] 0004_alter_user_username_opts
[X] 0005_alter_user_last_login_null
[X] 0006_require_contenttypes_0002
[X] 0007_alter_validators_add_error_messages
[X] 0008_alter_user_username_max_length
[X] 0009_alter_user_last_name_max_length
[X] 0010_alter_group_name_max_length
[X] 0011_update_proxy_permissions
[X] 0012_alter_user_first_name_max_length
contenttypes
[X] 0001_initial
[X] 0002_remove_content_type_name
gradebook
(no migrations)
sessions
[X] 0001_initial
sites
[X] 0001_initial
[X] 0002_alter_domain_unique
Where account is from django-allauth.
It looks like my apps are not being migrated. So I then do:
me#myserver:/home$ dokku run gradebook python manage.py makemigrations accounts
success
Migrations for 'accounts':
accounts/migrations/0001_initial.py
- Create model CustomUser
me#myserver:/home$
And it looks like things are ready migrate. I then run migrate and get an error django - ValueError: Dependency on app with no migrations: accounts:
shmish#Henry:/home$ dokku run gradebook python manage.py migrate accounts
success
Traceback (most recent call last):
File "/app/.heroku/python/lib/python3.8/site-packages/django/db/migrations/loader.py", line 174, in check_key
return self.graph.root_nodes(key[0])[0]
IndexError: list index out of range
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "manage.py", line 22, in <module>
main()
File "manage.py", line 18, in main
execute_from_command_line(sys.argv)
File "/app/.heroku/python/lib/python3.8/site-packages/django/core/management/__init__.py", line 419, in execute_from_command_line
utility.execute()
File "/app/.heroku/python/lib/python3.8/site-packages/django/core/management/__init__.py", line 413, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/app/.heroku/python/lib/python3.8/site-packages/django/core/management/base.py", line 354, in run_from_argv
self.execute(*args, **cmd_options)
File "/app/.heroku/python/lib/python3.8/site-packages/django/core/management/base.py", line 398, in execute
output = self.handle(*args, **options)
File "/app/.heroku/python/lib/python3.8/site-packages/django/core/management/base.py", line 89, in wrapped
res = handle_func(*args, **kwargs)
File "/app/.heroku/python/lib/python3.8/site-packages/django/core/management/commands/migrate.py", line 92, in handle
executor = MigrationExecutor(connection, self.migration_progress_callback)
File "/app/.heroku/python/lib/python3.8/site-packages/django/db/migrations/executor.py", line 18, in __init__
self.loader = MigrationLoader(self.connection)
File "/app/.heroku/python/lib/python3.8/site-packages/django/db/migrations/loader.py", line 53, in __init__
self.build_graph()
File "/app/.heroku/python/lib/python3.8/site-packages/django/db/migrations/loader.py", line 235, in build_graph
self.add_external_dependencies(key, migration)
File "/app/.heroku/python/lib/python3.8/site-packages/django/db/migrations/loader.py", line 199, in add_external_dependencies
parent = self.check_key(parent, key[0])
File "/app/.heroku/python/lib/python3.8/site-packages/django/db/migrations/loader.py", line 181, in check_key
raise ValueError("Dependency on app with no migrations: %s" % key[0])
ValueError: Dependency on app with no migrations: accounts
2021/08/25 16:19:16 exit status 1
At this point I am unable to migrate either of my apps. Another thing I find strange about this is that I'm still able to createsuperuser, go into the shell, from accounts.models import CustomUser and successfully query CustomUser.
This error looks similar to this: ValueError: Dependency on app with no migrations: account but I don't see a solution.
Next
I re-created my database on my dev and prod servers. On dev I re-ran the initial migrations and then committed to my repository. I then deployed to my production server. The migrations appear to work but I am unable to get past the login and signup forms. I've been unable to determine what the exact error is, but the page times out and gives a message "We're sorry, but something went wrong." which I assume is an nginx message.
After a few attempts at deploys to fix the problem I get new migration errors:
Your models in app(s): 'account' have changes that are not yet reflected in a migration, and so won't be applied.
Run 'manage.py makemigrations' to make new migrations, and then re-run 'manage.py migrate' to apply them.
This is an endless circle of makemigrations which appear to work, then migrate, then the error comes back up.
Note - I'm able to go into the shell and manually create a CustomUser object, but I'm unable to get past the forms on the first page of the website.
This is now looking just like this error from 2015: Django Heroku Error "Your models have changes that are not yet reflected in a migration"
All of this works fine on my dev environment, the big difference being that it is Docker while prod is Dokku.

check your git ignore, makesure folder migration comment or delete from gitignore file

Related

Django Migration difference between dev and test postgres databases

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'),
),
]
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).
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.

Does makemigrations in django recreates existing tables for a reason?

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.

Django migration stuck

I have a new field to add to my db. So I say
python manage.py makemigrations
which correctly creates kernel/migrations/0003_auto_20150726_1911.py. I inspect the contents and all looks good.
I say
python manage.py migrate
and I am less happy. The file kernel/migrations/0002_auto_20150707_1459.py, which adds field date_of_birth to table userprofile, fails. Even though I'm pretty sure that migration is applied. And so migration 0003 is never applied.
This is production. :(
I'm not at all sure what to do in order to apply 0003 and not hose django. Suggestions?
The rest of this is supporting docs:
The migrations
╭╴ (master=) [virt]╶╮
╰ [T] django#beta13:migrations $ cat 0002_auto_20150707_1459.py
# -*- coding: utf-8 -*-
from __future__ import unicode_literals
from django.db import models, migrations
class Migration(migrations.Migration):
dependencies = [
('kernel', '0001_initial'),
]
operations = [
migrations.AlterField(
model_name='userprofile',
name='date_of_birth',
field=models.DateField(null=True, blank=True),
),
]
╭╴ (master=) [virt]╶╮
╰ [T] django#beta13:migrations $ cat 0003_auto_20150726_1911.py
# -*- coding: utf-8 -*-
from __future__ import unicode_literals
from django.db import models, migrations
from django.conf import settings
class Migration(migrations.Migration):
dependencies = [
migrations.swappable_dependency(settings.AUTH_USER_MODEL),
('kernel', '0002_auto_20150707_1459'),
]
operations = [
migrations.AddField(
model_name='trippending',
name='requesting_user',
field=models.ForeignKey(default=1, related_name='trippending_requesting', to=settings.AUTH_USER_MODEL),
preserve_default=False,
),
migrations.AddField(
model_name='userprofile',
name='can_see_pending_trips',
field=models.BooleanField(default=False),
),
]
╭╴ (master=) [virt]╶╮
╰ [T] django#beta13:migrations $
The error
(The site runs in French, but I think the error is clear anyway.)
╭╴ (master %=) [virt]╶╮
╰ [T] django#beta13:django $ python manage.py migrate
Operations to perform:
Synchronize unmigrated apps: staticfiles, messages, admindocs
Apply all migrations: admin, sessions, custom_user, auth, kernel, contenttypes, registration, sites
Synchronizing apps without migrations:
Creating tables...
Running deferred SQL...
Installing custom SQL...
Running migrations:
Rendering model states... DONE
Applying kernel.0002_auto_20150707_1459...Traceback (most recent call last):
File "manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "/src/django/venv/lib/python3.4/site-packages/django/core/management/__init__.py", line 338, in execute_from_command_line
utility.execute()
File "/src/django/venv/lib/python3.4/site-packages/django/core/management/__init__.py", line 330, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/src/django/venv/lib/python3.4/site-packages/django/core/management/base.py", line 390, in run_from_argv
self.execute(*args, **cmd_options)
File "/src/django/venv/lib/python3.4/site-packages/django/core/management/base.py", line 441, in execute
output = self.handle(*args, **options)
File "/src/django/venv/lib/python3.4/site-packages/django/core/management/commands/migrate.py", line 221, in handle
executor.migrate(targets, plan, fake=fake, fake_initial=fake_initial)
File "/src/django/venv/lib/python3.4/site-packages/django/db/migrations/executor.py", line 110, in migrate
self.apply_migration(states[migration], migration, fake=fake, fake_initial=fake_initial)
File "/src/django/venv/lib/python3.4/site-packages/django/db/migrations/executor.py", line 147, in apply_migration
state = migration.apply(state, schema_editor)
File "/src/django/venv/lib/python3.4/site-packages/django/db/migrations/migration.py", line 115, in apply
operation.database_forwards(self.app_label, schema_editor, old_state, project_state)
File "/src/django/venv/lib/python3.4/site-packages/django/db/migrations/operations/fields.py", line 201, in database_forwards
schema_editor.alter_field(from_model, from_field, to_field)
File "/src/django/venv/lib/python3.4/site-packages/django/db/backends/base/schema.py", line 484, in alter_field
old_db_params, new_db_params, strict)
File "/src/django/venv/lib/python3.4/site-packages/django/db/backends/base/schema.py", line 571, in _alter_field
old_default = self.effective_default(old_field)
File "/src/django/venv/lib/python3.4/site-packages/django/db/backends/base/schema.py", line 211, in effective_default
default = field.get_db_prep_save(default, self.connection)
File "/src/django/venv/lib/python3.4/site-packages/django/db/models/fields/__init__.py", line 710, in get_db_prep_save
prepared=False)
File "/src/django/venv/lib/python3.4/site-packages/django/db/models/fields/__init__.py", line 1322, in get_db_prep_value
value = self.get_prep_value(value)
File "/src/django/venv/lib/python3.4/site-packages/django/db/models/fields/__init__.py", line 1317, in get_prep_value
return self.to_python(value)
File "/src/django/venv/lib/python3.4/site-packages/django/db/models/fields/__init__.py", line 1287, in to_python
params={'value': value},
django.core.exceptions.ValidationError: ["Le format de date de la valeur «\xa0\xa0» n'est pas valide. Le format correct est AAAA-MM-JJ."]
╭╴ (master %=) [virt]╶╮
╰ 1,[T] django#beta13:django $
The data
I checked with postgres, expecting to find something amiss. But all looks fine.
mydb=# select date_of_birth from kernel_userprofile;
date_of_birth
---------------
2018-10-23
1972-05-31
1978-10-21
2008-12-29
1967-08-26
2015-07-26
(6 rows)
mydb=#
For the community, the issue was django_migrations table was not updated with 0002_auto_20150707_1459 even though the migration was actually applied on table as mentioned in the post.
The solution was to insert a new row in django_migrations table with data like below so migration 0002 was skipped.
INSERT INTO DJANGO_MGRATIONS ('app', 'name', 'applied') VALUES ('appname', '0002_auto_20150707_1459', '2015-07-07 00:00')
Skipping migration must be done with extreme caution, hence check all details before skipping.
Same trouble happend, but without any logs
At first I determined what app was a problem, by running
python manage.py migrate app_name
for every django app
after that I check migrations for app by running
python manage.py showmigrations app_name
And marked first uncompleted migration as completed by running
python manage.py migrate --fake app_name migration_name
※ about fake
And that was a solution in my case
For anyone finding this post: I just helped a coworker debug a similar problem (same error message), and in this case the source of the problem was trying to give the DateField a default value of u"" (which is of course invalid for a date) instead of None.
Actually part of the fun was that the previous migration (which created the model) already had this wrong default but still ran seamlessly, the error only appearing when trying to alter the field in any way.
The fix required editing the previous migration to set the sane default value, since Django uses the previous migration's schema description to get the previous default value.

How to run migrations for a new server

I am trying to deploy my Django-cms site on Heroku, and I'm really struggling with migrations. I'm running django 1.7.7 and django-cms 3.1.0. I don't have any data to migrate, so I just want to create the empty tables.
With a fresh Heroku Postgres database:
heroku run python manage.py migrate contenttypes
output:
Operations to perform:
Apply all migrations: contenttypes
Running migrations:
Applying contenttypes.0001_initial...Traceback (most recent call last):
File "manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "/app/.heroku/python/lib/python3.4/site-packages/django/core/management/__init__.py", line 385, in execute_from_command_line
utility.execute()
File "/app/.heroku/python/lib/python3.4/site-packages/django/core/management/__init__.py", line 377, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/app/.heroku/python/lib/python3.4/site-packages/django/core/management/base.py", line 288, in run_from_argv
self.execute(*args, **options.__dict__)
File "/app/.heroku/python/lib/python3.4/site-packages/django/core/management/base.py", line 338, in execute
output = self.handle(*args, **options)
File "/app/.heroku/python/lib/python3.4/site-packages/django/core/management/commands/migrate.py", line 161, in handle
executor.migrate(targets, plan, fake=options.get("fake", False))
File "/app/.heroku/python/lib/python3.4/site-packages/django/db/migrations/executor.py", line 68, in migrate
self.apply_migration(migration, fake=fake)
File "/app/.heroku/python/lib/python3.4/site-packages/django/db/migrations/executor.py", line 96, in apply_migration
if self.detect_soft_applied(migration):
File "/app/.heroku/python/lib/python3.4/site-packages/django/db/migrations/executor.py", line 140, in detect_soft_applied
apps = project_state.render()
File "/app/.heroku/python/lib/python3.4/site-packages/django/db/migrations/state.py", line 75, in render
"for more" % new_unrendered_models
django.db.migrations.state.InvalidBasesError: Cannot resolve bases for [<ModelState: 'djangocms_link.Link'>, <ModelState: 'djangocms_text_ckeditor.Text'>, <ModelState: 'djangocms_file.File'>, <ModelState: 'djangocms_inherit.InheritPagePlaceholder'>, <ModelState: 'djangocms_column.MultiColumns'>, <ModelState: 'djangocms_column.Column'>, <ModelState: 'djangocms_googlemap.GoogleMap'>, <ModelState: 'djangocms_flash.Flash'>, <ModelState: 'djangocms_snippet.SnippetPtr'>, <ModelState: 'djangocms_video.Video'>, <ModelState: 'djangocms_teaser.Teaser'>, <ModelState: 'djangocms_picture.Picture'>]
This can happen if you are inheriting models from an app with migrations (e.g. contrib.auth)
in an app with no migrations; see https://docs.djangoproject.com/en/1.7/topics/migrations/#dependencies for more
What I don't understand is that contenttypes doesn't depend on any of those models in the djangocms plugins. If I try to migrate any of the plugins first, I get a stack trace and this:
RuntimeError: Error creating new content types. Please make sure contenttypes is migrated before trying to migrate apps individually.
UPDATE: Following the documentation for the various django-cms plugins, I added MIGRATION_MODULES to settings.py. Now when I run:
heroku run python manage.py makemigrations djangocms_text_ckeditor
a migration is created:
Migrations for 'djangocms_text_ckeditor':
0001_initial.py:
- Create model Text
Sounds great! But...
heroku run python manage.py migrate djangocms_text_ckeditor
output:
Operations to perform:
Apply all migrations: (none)
Running migrations:
No migrations to apply.
Your models have changes that are not yet reflected in a migration, and so won't be applied.
Run 'manage.py makemigrations' to make new migrations, and then re-run 'manage.py migrate' to apply them.
Traceback (most recent call last):
File "/app/.heroku/python/lib/python3.4/site-packages/django/contrib/contenttypes/models.py", line 44, in get_for_model
ct = self._get_from_cache(opts)
File "/app/.heroku/python/lib/python3.4/site-packages/django/contrib/contenttypes/models.py", line 34, in _get_from_cache
return self.__class__._cache[self.db][key]
KeyError: 'default'
During handling of the above exception, another exception occurred:
[long stack trace ommitted]
As stated in djangocms_link module documentation - https://github.com/divio/djangocms-link
If using Django 1.7 add 'djangocms_link': 'djangocms_link.migrations_django', to MIGRATION_MODULES
And same for djangocms_file module
So basically you should have in your settings.py
MIGRATION_MODULES = {
'djangocms_link': 'djangocms_link.migrations_django',
'djangocms_file': 'djangocms_file.migrations_django'
}

south.exceptions.NoMigrations error for Django South

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.