#33483: Index name migration instability between database engines
-------------------------------------+-------------------------------------
Reporter: Marti Raudsepp | Owner: nobody
Type: Bug | Status: closed
Component: Database layer | Version: 4.0
(models, ORM) |
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage:
oracle,migrations,indexes | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Mariusz Felisiak):
* status: new => closed
* resolution: => wontfix
Comment:
Thanks for the report.
> I think this is a bug in Django -- generally the expectation seems to be
that migration files are portable between databases.
Unfortunately, database backends (even builtin) will never be fully
swappable.
> On the other hand, it would be nice to bump Oracle's `max_name_length()`
anyway. The current 30-character limit is already obsolete. Django 4.0
officially only supports Oracle 19c and newer. In Oracle 12.2 and above
the maximum object name length is 128 bytes, not 30.
I think it is not a feasible option, see #30684. Moreover this
[https://docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf
/Database-Object-Names-and-Qualifiers.html#GUID-75337742-67FD-4EC0-985F-
741C93D918DA can be changed] via `COMPATIBLE` parameter.
> If the logic in `Index.set_name_with_model()` were to change -- for
example to use un-truncated table name -- then after upgrading to that
Django version, Django migrations out of the box would re-create all these
indexes. For users with large databases, recreating indexes may cause
significant disruption.
>
> So some compatibility logic for legacy index names seems warranted.
Although for my personal use case, I wouldn't mind a fix that requires
such "flag-day" migrations.
IMO it's not doable, because we don't have a clean and backward compatible
path, basically from the same reason as #30684. I would recommend adding
`db_table` (as you did for `django-celery-results`) or using a
[https://docs.djangoproject.com/en/4.0/ref/databases/#subclassing-the-
built-in-database-backends backend subclass] to override
`max_name_length()` in your own project.
I really would like to unify this, however we cannot do this without a
backward compatible solution.
--
Ticket URL: <https://code.djangoproject.com/ticket/33483#comment:5>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/063.043f17a1c980ba818ef4576950910d2d%40djangoproject.com.
