evewspace / eve-wspace

Wormhole mapping and corporation management for Eve Online.
Apache License 2.0
86 stars 51 forks source link

migration fails when switching from crest to develop branch #265

Closed EvilGrinUK closed 7 years ago

EvilGrinUK commented 7 years ago

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")
EvilGrinUK commented 7 years ago

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

Maarten28 commented 7 years ago

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.

EvilGrinUK commented 7 years ago

Ah I didn't know you could do that, TIL. :bulb:

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.