-
Notifications
You must be signed in to change notification settings - Fork 393
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix index collision in 0008_gfk_index migration #458
base: develop
Are you sure you want to change the base?
Conversation
@chrisspen I believe this now fully addresses the problem you reported in #457. I think the root cause of that problem lies more with the index collision than with migration dependency resolution. |
test were done against sqlite3 and postgresql migrations were successful using empty databases |
We're using PostgreSQL, although non-empty. Sqlite3 sometimes allows subtle errors like this because it doesn't support a lot of features other databases have. |
Yeah, after further testing last night I'm not 100% sure this is a you problem... might be an us problem, since I was unable to reproduce it with a new model created in Postgres with I'm now tempted to close this PR and override the migration in our project with the Will continue looking into this until I get too frustrated/bored :) |
(note how
|
I use psycopg2 and PostgreSQL and do not see these errors. What versions of those are you using? Can you try the latest release and see if you still experience the issue? I have made some fixes for migrations that I noticed, but the error is different. |
Postgres 11.5, psycopg2 2.8.3, django 2.2.6, django-scheduler 0.9.2 Will try again from master and continue investigating. |
Okay, at this point I suppose I'll have to settle for overriding migrations in our project ( |
When schedule migrations are run for the first time, the following exception occurs for migration 0008_gfk_index:
psycopg2.errors.DuplicateTable: relation "schedule_calendar_slug_ba17e861_like" already exists
.This appears to be due to Django attempting to set the
_like
index after addingunique=True
to theCalendar.slug
field, for whichdb_index=True
was already set due to being aSlugField
. The initial migration created the_like
index, and making an already indexed field unique causes the index collision.This is the best fix I could come up with. I'll continue investigating and potentially file a bug with Django if it turns out to be trivially reproducible.