migration fails when switching from crest to develop branch
EvilGrinUK opened this issue · comments
See #162 discussion for background. I don't know if it broke because of the branch switch or because there is something wrong with the migration code. If it's the former I guess it doesn't matter really.
Error during the migration is:
Applying djcelery.0001_initial...Traceback (most recent call last):
File "./manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "/home/maptool/eve-wspace/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 354, in execute_from_command_line
utility.execute()
File "/home/maptool/eve-wspace/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 346, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/home/maptool/eve-wspace/local/lib/python2.7/site-packages/django/core/management/base.py", line 394, in run_from_argv
self.execute(*args, **cmd_options)
File "/home/maptool/eve-wspace/local/lib/python2.7/site-packages/django/core/management/base.py", line 445, in execute
output = self.handle(*args, **options)
File "/home/maptool/eve-wspace/local/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 "/home/maptool/eve-wspace/local/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 "/home/maptool/eve-wspace/local/lib/python2.7/site-packages/django/db/migrations/executor.py", line 148, in apply_migration
state = migration.apply(state, schema_editor)
File "/home/maptool/eve-wspace/local/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 "/home/maptool/eve-wspace/local/lib/python2.7/site-packages/django/db/migrations/operations/models.py", line 59, in database_forwards
schema_editor.create_model(model)
File "/home/maptool/eve-wspace/local/lib/python2.7/site-packages/django/db/backends/base/schema.py", line 286, in create_model
self.execute(sql, params or None)
File "/home/maptool/eve-wspace/local/lib/python2.7/site-packages/django/db/backends/base/schema.py", line 111, in execute
cursor.execute(sql, params)
File "/home/maptool/eve-wspace/local/lib/python2.7/site-packages/django/db/backends/utils.py", line 79, in execute
return super(CursorDebugWrapper, self).execute(sql, params)
File "/home/maptool/eve-wspace/local/lib/python2.7/site-packages/django/db/backends/utils.py", line 64, in execute
return self.cursor.execute(sql, params)
File "/home/maptool/eve-wspace/local/lib/python2.7/site-packages/django/db/utils.py", line 98, in __exit__
six.reraise(dj_exc_type, dj_exc_value, traceback)
File "/home/maptool/eve-wspace/local/lib/python2.7/site-packages/django/db/backends/utils.py", line 62, in execute
return self.cursor.execute(sql)
File "/home/maptool/eve-wspace/local/lib/python2.7/site-packages/django/db/backends/mysql/base.py", line 124, in execute
return self.cursor.execute(query, args)
File "/home/maptool/eve-wspace/local/lib/python2.7/site-packages/MySQLdb/cursors.py", line 205, in execute
self.errorhandler(self, exc, value)
File "/home/maptool/eve-wspace/local/lib/python2.7/site-packages/MySQLdb/connections.py", line 36, in defaulterrorhandler
raise errorclass, errorvalue
django.db.utils.OperationalError: (1050, "Table 'djcelery_crontabschedule' already exists")
The migrations worked fine updating my Ubuntu 16.04 install that had only had the develop branch. So I think this is purely an issue switching when from crest to develop
Since you already have a djcelery_crontabschedule table you apply that specific migration with the --fake option behind it.
python manage.py migrate djcelery 0001 --fake
Should do the trick.
After this you can run all the other migrations as usual.
Btw, this issue will also exist if you have any version running of the tool older then a week. Not specifically only from the CREST branch.
Ah I didn't know you could do that, TIL. 💡
It's not a big deal as the Ubuntu 16.04 EC2 instance works fine with the updated requirements.txt and I'd rather be on the newer Ubuntu LTS release. So I can just trash this instance.