psycopg2.errors.DuplicateTable: relation "django_celery_beat_solarschedule" already exists - django

While deployment django project I see the following error and not clear what is missing. We deleted previous migrations too before deploying but no change in the result:
Apply all migrations: admin, auth, captcha, contenttypes, django_celery_beat, django_celery_results, hitcount, sessions, watson
Running migrations:
Applying django_celery_beat.0002_auto_20161118_0346...Traceback (most recent call last):
File "/home/jenkins/workspace/dev-jk-project/env/lib/python3.10/site-packages/django/db/backends/utils.py", line 87, in _execute
return self.cursor.execute(sql)
psycopg2.errors.DuplicateTable: relation "django_celery_beat_solarschedule" already exists
Please let me know if you are able to fix this?

Related

django - ValueError: Dependency on app with no migrations

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

How do I fix a ProgrammingError at /admin/login/ (1146, "Table 'torquedb.showroom_customuser' doesn't exist")

I created a CustomUser using the Django allAuth package. Allowing users to sign-up and log in via email rather than usernames was the primary reason why.
When I try logging into the admin with my superuser account, it throws this error:
ProgrammingError at /admin/login/
(1146, "Table 'torquedb.showroom_customuser' doesn't exist")
Admin.py for the customuser
#admin.register(CustomUser)
class CustomUserAdmin(admin.ModelAdmin):
add_form = CustomUserCreationForm
form = CustomUserChangeForm
model = CustomUser
list_display = ['email', 'username', 'phone_number', 'website']
The CustomUser models.py
from django.contrib.auth.models import AbstractUser
class CustomUser(AbstractUser):
phone_number = models.IntegerField(default='07')
website = models.CharField(max_length=50)
def __str__(self):
return f'{self.name}'
I've tried running new migrations with
py manage.py makemigrations
py manage.py migrate
py manage.py migrate showroom (the app name)
I've already dropped and recreated the MariaDB database (called torquedb) a few times, and this is a new one with all migrations up to date. Again, they all state that they are up to date.
Update
This issue is probably directly related to the custom user I created using Django allauth. When I tried to migrate it, this error was raised:
raise ValueError('Related model %r cannot be resolved' % self.remote_field.model)
ValueError: Related model 'showroom.CustomUser' cannot be resolved
Even though all other migrations worked fine. So I ran py manage.py migrate --fake to fake the migration and everything else worked fine.
I know faking migrations doesn't actually make the migrations, which is the problem, but I can't still can't figure out how to solve it.
After purging the database and starting afresh, this is the error produced.
(torque) C:\code\torque>py manage.py makemigrations No changes detected (torque) C:\code\torque>py manage.py migrate showroom Operations to perform: Apply all migrations: showroom Running migrations: Applying contenttypes.0001_initial... OK Applying contenttypes.0002_remove_content_type_name... OK Applying auth.0001_initial... OK 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 auth.0007_alter_validators_add_error_messages... OK Applying auth.0008_alter_user_username_max_length... OK Applying auth.0009_alter_user_last_name_max_length... OK Applying auth.0010_alter_group_name_max_length... OK Applying auth.0011_update_proxy_permissions... OK Applying showroom.0001_initial... OK Applying account.0001_initial... OK Applying account.0002_email_max_length... OK Applying account.0003_auto_20191015_1328... OK Applying admin.0001_initial... OK Applying admin.0002_logentry_remove_auto_add... OK Applying admin.0003_logentry_add_action_flag_choices... OK Applying admin.0004_auto_20191015_1328... OK Applying sites.0001_initial... OK Applying socialaccount.0001_initial... OK Applying socialaccount.0002_token_max_lengths... OK Applying socialaccount.0003_extra_data_default_dict... OK Applying socialaccount.0004_auto_20191015_1328... OK Applying showroom.0002_auto_20191015_1328...Traceback (most recent call last): File "manage.py", line 21, in <module> main() File "manage.py", line 17, in main execute_from_command_line(sys.argv) File "C:\Users\USER\Envs\torque\lib\site-packages\django\core\management\__init__.py", line 381, in execute_from_command_line utility.execute() File "C:\Users\USER\Envs\torque\lib\site-packages\django\core\management\__init__.py", line 375, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File "C:\Users\USER\Envs\torque\lib\site-packages\django\core\management\base.py", line 323, in run_from_argv self.execute(*args, **cmd_options) File "C:\Users\USER\Envs\torque\lib\site-packages\django\core\management\base.py", line 364, in execute output = self.handle(*args, **options) File "C:\Users\USER\Envs\torque\lib\site-packages\django\core\management\base.py", line 83, in wrapped res = handle_func(*args, **kwargs) File "C:\Users\USER\Envs\torque\lib\site-packages\django\core\management\commands\migrate.py", line 234, in handle fake_initial=fake_initial, File "C:\Users\USER\Envs\torque\lib\site-packages\django\db\migrations\executor.py", line 117, in migrate state = self._migrate_all_forwards(state, plan, full_plan, fake=fake, fake_initial=fake_initial) File "C:\Users\USER\Envs\torque\lib\site-packages\django\db\migrations\executor.py", line 147, in _migrate_all_forwards state = self.apply_migration(state, migration, fake=fake, fake_initial=fake_initial) File "C:\Users\USER\Envs\torque\lib\site-packages\django\db\migrations\executor.py", line 245, in apply_migration state = migration.apply(state, schema_editor) File "C:\Users\USER\Envs\torque\lib\site-packages\django\db\migrations\migration.py", line 124, in apply operation.database_forwards(self.app_label, schema_editor, old_state, project_state) File "C:\Users\USER\Envs\torque\lib\site-packages\django\db\migrations\operations\fields.py", line 249, in database_forwards schema_editor.alter_field(from_model, from_field, to_field) File "C:\Users\USER\Envs\torque\lib\site-packages\django\db\backends\base\schema.py", line 507, in alter_field new_db_params = new_field.db_parameters(connection=self.connection) File "C:\Users\USER\Envs\torque\lib\site-packages\django\db\models\fields\related.py", line 966, in db_parameters return {"type": self.db_type(connection), "check": self.db_check(connection)} File "C:\Users\USER\Envs\torque\lib\site-packages\django\db\models\fields\related.py", line 963, in db_type return self.target_field.rel_db_type(connection=connection) File "C:\Users\USER\Envs\torque\lib\site-packages\django\db\models\fields\related.py", line 878, in target_field return self.foreign_related_fields[0] File "C:\Users\USER\Envs\torque\lib\site-packages\django\db\models\fields\related.py", line 632, in foreign_related_fields return tuple(rhs_field for lhs_field, rhs_field in self.related_fields if rhs_field) File "C:\Users\USER\Envs\torque\lib\site-packages\django\db\models\fields\related.py", line 619, in related_fields self._related_fields = self.resolve_related_fields() File "C:\Users\USER\Envs\torque\lib\site-packages\django\db\models\fields\related.py", line 604, in resolve_related_fields raise ValueError('Related model %r cannot be resolved' % self.remote_field.model) ValueError: Related model 'showroom.CustomUser' cannot be resolved
Then I fake the migration
(torque) C:\code\torque>py manage.py migrate --fake showroom Operations to perform: Apply all migrations: showroom Running migrations: Applying showroom.0002_auto_20191015_1328... FAKED Applying showroom.0003_auto_20191015_1329... FAKED
As per documentation on changing to a custom user model mid-project:
Changing AUTH_USER_MODEL after you’ve created database tables is significantly more difficult since it affects foreign keys and many-to-many relationships, for example.
This change can’t be done automatically and requires manually fixing your schema, moving your data from the old user table, and possibly manually reapplying some migrations
So, I think all you need to
Delete all the migration files(which reside in <any app directory>/migration, also don't remove the __init__.py file from the migration directory) from all the apps
Drop the database and create new one.
re-create all the migration using ./manage.py makemigrations and migrate using ./manage.py migrate.
More information can be found in ticket: #25313 where you can do the changes without loosing the data in DB. You can also checkout my blog post as well.
Also looking into your code, probably you should use:
#admin.register(CustomUser)
class CustomUserAdmin(admin.ModelAdmin):
# ^^^^^^^^^^^^^^^^^
When adding the model to admin site.

Django error relation "auth_user" does not exist using multiple database

I'm working on Django 1.9 and python 3.3 project using multiple databases (different schema in a same postgresql database). When I try to migrate the project for the first time, I'm getting this error
Running migrations:
Rendering model states... DONE
Applying contenttypes.0001_initial... OK
Applying auth.0001_initial... OK
Applying MyApp.0001_initial...Traceback (most recent call last):
File "/usr/lib/python3.4/site-packages/django/db/backends/utils.py", line 64, in execute
return self.cursor.execute(sql, params)
psycopg2.ProgrammingError: ERROR: relation "auth_user" does not exist
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "manage.py", line 10, in
execute_from_command_line(sys.argv)
File "/usr/lib/python3.4/site-packages/django/core/management/__init__.py", line 350, in execute_from_command_line
utility.execute()
File "/usr/lib/python3.4/site-packages/django/core/management/__init__.py", line 342, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/usr/lib/python3.4/site-packages/django/core/management/base.py", line 348, in run_from_argv
self.execute(*args, **cmd_options)
File "/usr/lib/python3.4/site-packages/django/core/management/base.py", line 399, in execute
output = self.handle(*args, **options)
File "/usr/lib/python3.4/site-packages/django/core/management/commands/migrate.py", line 200, in handle
executor.migrate(targets, plan, fake=fake, fake_initial=fake_initial)
File "/usr/lib/python3.4/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/lib/python3.4/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/lib/python3.4/site-packages/django/db/migrations/executor.py", line 198, in apply_migration
state = migration.apply(state, schema_editor)
File "/usr/lib/python3.4/site-packages/django/db/backends/base/schema.py", line 90, in __exit__
self.execute(sql)
File "/usr/lib/python3.4/site-packages/django/db/backends/base/schema.py", line 110, in execute
cursor.execute(sql, params)
File "/usr/lib/python3.4/site-packages/django/db/backends/utils.py", line 79, in execute
return super(CursorDebugWrapper, self).execute(sql, params)
File "/usr/lib/python3.4/site-packages/django/db/backends/utils.py", line 64, in execute
return self.cursor.execute(sql, params)
File "/usr/lib/python3.4/site-packages/django/db/utils.py", line 95, in __exit__
six.reraise(dj_exc_type, dj_exc_value, traceback)
File "/usr/lib/python3.4/site-packages/django/utils/six.py", line 685, in reraise
raise value.with_traceback(tb)
File "/usr/lib/python3.4/site-packages/django/db/backends/utils.py", line 64, in execute
return self.cursor.execute(sql, params)
django.db.utils.ProgrammingError: ERROR: relation "auth_user" does not exist
This error seems to appeard in other projects when the auth_user table isn't migrated. In my case beginning my migration with manage.py migrate auth before migrating the app who need it doesn't solve the problem.
I suspect that the problem come from the use of different database in Django. My auth_user table is stored in the default database and the content of the models.py is routed to an other database.
Is the migration process looking for the auth_user table in the same database than my app database? Is it something absolutely different?
Answer to the problem
It is in fact a cross database reference problem. Django can't create cross database foreign keys.
From the Django 1.8 documentation (and there isn't any solution in the next versions (current version is 1.10)) :
Cross-database relations
Django doesn’t currently provide any support for foreign key or
many-to-many relationships spanning multiple databases. If you have
used a router to partition models to different databases, any foreign
key and many-to-many relationships defined by those models must be
internal to a single database.
This is because of referential integrity. In order to maintain a
relationship between two objects, Django needs to know that the
primary key of the related object is valid. If the primary key is
stored on a separate database, it’s not possible to easily evaluate
the validity of a primary key.
If you’re using Postgres, Oracle, or MySQL with InnoDB, this is
enforced at the database integrity level – database level key
constraints prevent the creation of relations that can’t be validated.
However, if you’re using SQLite or MySQL with MyISAM tables, there is
no enforced referential integrity; as a result, you may be able to
‘fake’ cross database foreign keys. However, this configuration is not
officially supported by Django
How to workaround and keep separate databases
In my case, because router are working, there is a little hack to simplify the cross database objects.
class CrossDBUser(models.Model):
user = models.IntegerField()
def get_user(self):
return User.objects.get(id=self.user)
def set_user(self, user):
self.user = user.id
class MyClassWithCrossDB(CrossDBUser):
field1 = models.CharField(max_length=200, blank=False)
field2 = models.IntegerField(default=0)
With this I can use the method set_user and get_user to work with the user stored in my object MyClassWithCrossDB.
Of course it's not perfect because it doesn't allow automated actions like on_delete=models.CASCADE and I'm obliged to work with methods instead of the instance variable. But it is a solution to workaround.

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.

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'
}