Giters

celery / django-celery-results

Celery result back end with django

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

migrations\0009_groupresult.py failing

zenoran opened this issue · comments

commented

Oracle backend

Trying to upgrade to 2.3.1 (coming from 2.0.1) and getting error on running migrations.

Running migrations: Applying django_celery_results.0009_groupresult...Traceback (most recent call last): File "app\.venv\lib\site-packages\django\db\backends\utils.py", line 82, in _execute return self.cursor.execute(sql) File "app\.venv\lib\site-packages\django\db\backends\oracle\base.py", line 510, in execute return self.cursor.execute(query, self._param_generator(params)) cx_Oracle.DatabaseError: ORA-00955: name is already used by an existing object

I was reading through the script and it appears there is something in there trying to avoid this but it doesn't appear to be working? I fixed this on a local installation by dropping the tables and re-running the migration scripts but that isn't feasible for pushing to higher environments. This is tricky to try and bypass since the migrations are part of an external library vs. ones I have control over in my code.

commented

it seems to be an issue on your DB / code?

commented

I run into the same problem. As It turns out we had updated to 2.2.0 back in October and run into a bug / situation where we had to rollback to 2.0.1, but forgetting to properly undo the migration.

There are a number of ways to recover from this, depending on the state of the database:

  • Manually delete the database objects prior to migration
  • Check which migrations have completed and fake migrate these
  • Fake migrate all migrations and then rollback manage.py migrate django_celery_results 0008_chordcounter, then re-apply the migrations without faking

I ended up dropping one table prior to the migration:

 drop table DJANGO_CELERY_RESULTS_GROU9C87
/
commented

I run into the same problem. As It turns out we had updated to 2.2.0 back in October and run into a bug / situation where we had to rollback to 2.0.1, but forgetting to properly undo the migration.

There are a number of ways to recover from this, depending on the state of the database:

  • Manually delete the database objects prior to migration
  • Check which migrations have completed and fake migrate these
  • Fake migrate all migrations and then rollback manage.py migrate django_celery_results 0008_chordcounter, then re-apply the migrations without faking

I ended up dropping one table prior to the migration:

 drop table DJANGO_CELERY_RESULTS_GROU9C87
/

Thanks... I did find that it was due to some other combination of different versions which was only visible in one of the environments. Dropping the tables and re-running the migration scripts was the only solution.