Work around Oracle migration instability #283
Conversation
Fixes celery#222. Django's auto-generated index names are not stable across database engines: https://code.djangoproject.com/ticket/33483 Added explicit index names to `models.py` to work around that, until a fix is implemented in Django itself.
|
No, I used the same index names that Django was automatically generating on non-Oracle databases. Thus no migrations are generated. |
|
@felixxm can you please tell that we are not doing wrong? as you are an django ORM/oracle back end expert O:) |
Unfortunately the Django issue has been closed as "wontfix". I think it's fixable, but wouldn't be pretty and I don't know that I can find the time to PoC it. |
| @@ -95,12 +95,18 @@ class Meta: | |||
| verbose_name = _('task result') | |||
| verbose_name_plural = _('task results') | |||
|
|
|||
| # Explicit names to solve https://code.djangoproject.com/ticket/33483 | |||
There was a problem hiding this comment.
since the ticket is won't fix, I am reluctant to include this right now. Instead, can't we define index name in the model meta to generate nicer/shorter names?
There was a problem hiding this comment.
Not sure if I understand you correctly. I am defining index names in model meta.
I can change the names to be prettier, but then it would mean a migration that drops and re-creates all indexes, not just Oracle users (there's no RenameIndex migration in Django). For users who have lots of data, that can be disruptive. But if you think it's worth it, I can do it.
There was a problem hiding this comment.
Actually a 3rd option is to use db_index=True in field definitions, instead of defining Meta.indexes. Indexes created that way are database-engine-agnostic. But this would require a migration recreating indexes as well.
There was a problem hiding this comment.
These fields used to have db_index=True and were changed to the Meta, causing all sorts of index issues:
#161 (comment)
I agree the index names are ugly but they do match the name originally generated by Django preventing any additional index migrations, which has my preference.
Subclassing If it were a blessed solution by Django developers that all Oracle users should go this route to increase chances of compatibility, I would be willing to do it, but as it stands, I'm hesitant. I have to wonder, am I the only person trying to use django-celery-results on Oracle, or just the first one to notice and bother with this issue. It's becoming increasingly clear that the long-long term solution is to simply migrate from Oracle to PostgreSQL. But it's not happening soon. |
|
I do agree to some degree, allow me some time to properly recheck and comment. |
|
Thank you! Any plans for a release soon? :) |
Fixes #222 (as noted in the last comment, the issue still occurs)
Django's auto-generated index names are not stable across database engines: https://code.djangoproject.com/ticket/33483
Added explicit index names to
models.pyto work around that,until a fix is implemented in Django itself.