To reproduce:
- Install Django < 5.1
- Start a new project and a new app
- Create a model with `index_together` and run `makemigrations`
- or run `makemigrations` before adding `index_together` and run it
again so `AlterIndexTogether` operation is created, same result
- Write a test that uses the database (a simple test with `TestCase` and
not `SimpleTestCase` should suffice)
- Optional: Update the model to use `indexes` instead of `index_together`
and run `makemigrations`
- Install latest Django `main`
- Run `python manage.py test -v3` and it fails when applying the migration
that contains `index_together`
Reproducible example: https://github.com/laymonage/django-test-repro
This is likely because `"index_together"` has been removed from
`django.db.models.options.DEFAULT_NAMES` in
2abf417c815c20f41c0868d6f66520b32347106e. Meanwhile, the historical model
constructed by the migrations framework will try to build the model with
the `Meta.index_together` option.
I'm not sure if this is expected. If it is, then that means developers
have to update their old migrations to not use `index_together` at all,
which doesn't seem to be ideal.
If it is not, the solution might be to reintroduce `"index_together"` in
`DEFAULT_NAMES` even though it will be no-op. Not sure if that's all there
is to it, but I'm happy to make a PR for a start.
--
Ticket URL: <https://code.djangoproject.com/ticket/34856>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Comment (by Sage Abdullah):
To add, the [https://docs.djangoproject.com/en/dev/releases/4.2/#index-
together-option-is-deprecated-in-favor-of-indexes 4.2 release notes] do
say the following though:
> Next, consider squashing migrations to remove `index_together` from
historical migrations.
> The `AlterIndexTogether` migration operation is now officially supported
only for pre-Django 4.2 migration files. For backward compatibility
reasons, it’s still part of the public API, and there’s no plan to
deprecate or remove it, but it should not be used for new migrations. Use
`AddIndex` and `RemoveIndex` operations instead.
But with the problem in this ticket, it seems squashing the migrations
will be mandatory?
--
Ticket URL: <https://code.djangoproject.com/ticket/34856#comment:1>
* status: new => closed
* resolution: => invalid
Comment:
I was about to reply linking to the 4.2 release notes then saw you
answered your own question:
> To add, the 4.2 release notes do say the following though:
> ...
> But with the problem in this ticket, it seems squashing the migrations
will be mandatory?
Yes :)
--
Ticket URL: <https://code.djangoproject.com/ticket/34856#comment:2>
Comment (by David Sanders):
PS: If you disagree with the removal at the end of deprecation feel free
to start a thread on the Django forum:
https://www.djangoproject.com/community/
--
Ticket URL: <https://code.djangoproject.com/ticket/34856#comment:3>
Comment (by Sage Abdullah):
Replying to [comment:3 David Sanders]:
> PS: If you disagree with the removal at the end of deprecation feel free
to start a thread on the Django forum:
https://www.djangoproject.com/community/
Thanks! I don't mind the removal itself, though I wonder if the release
notes should be updated to better reflect the fact that squashing the
migrations will be mandatory? The current wording seems to suggest it's
optional. That said, this ticket is probably enough as additional
documentation about this issue if anyone else encounters it in the future.
--
Ticket URL: <https://code.djangoproject.com/ticket/34856#comment:4>