how to programmatically get the index name of a model field on a migration of django 1.8

[Fabio C. Barrionuevo da Luz]

Hello, I need to delete an index created automatically by Django, from a third-party application and my own django apps, for later I recreate the index optimized way.

this django application is used in several companies.
so I need to distribute these improvements via django migration.

I'm using raw sql in a RunPython migration, to delete and create the optimized index.

in django 1.8, there is a deterministic way to I previously know what the index name is generated for a given model field or django has a python function/method to get this information?

--

Fábio C. Barrionuevo da Luz
Palmas - Tocantins - Brasil - América do Sul

http://pythonclub.com.br/

Blog colaborativo sobre Python e tecnologias Relacionadas, mantido totalmente no https://github.com/pythonclub/pythonclub.github.io .

Todos são livres para publicar. É só fazer fork, escrever sua postagem e mandar o pull-request. Leia mais sobre como publicar em README.md e contributing.md.

Regra básica de postagem:

"Você" acha interessante? É útil para "você"? Pode ser utilizado com Python ou é útil para quem usa Python? Está esperando o que? Publica logo, que estou louco para ler...

[Michal Petrucha]

On Fri, Jun 29, 2018 at 11:25:16AM -0300, Fabio C. Barrionuevo da Luz wrote:
> Hello, I need to delete an index created automatically by Django, from a
> third-party application and my own django apps, for later I recreate the
> index optimized way.
>
> this django application is used in several companies.
> so I need to distribute these improvements via django migration.
>
>
> I'm using raw sql in a RunPython migration, to delete and create the
> optimized index.
>
> in django 1.8, there is a deterministic way to I previously know what the
> index name is generated for a given model field or django has a python
> function/method to get this information?

I'm not sure if the names are generated in a predictable way, but my
gut says they probably aren't – at least not in general, maybe for
certain specific DB backends, they will be. (As far as I can see, in
the base backend implementation, Django introspects existing indices
in the database, and finds the name that way.)

If the index is created with db_index=True, unique=true,
index_together, or unique_together, you might be able to get away with
a migration with two operations:
1. delete the index with an AlterField, AlterUniqueTogether, or
AlterIndexTogether operation, and then
2. use SeparateDatabaseAndState, and in `state_operations`, you undo
the effect of the previous operation, while in
`database_operations`, you'd execute your custom SQL to create the
optimized index.

Another option might be to use a RunPython operation, in which you use
the schema_editor passed in to drop the index with its alter_field,
alter_unique_together, or alter_index_together methods, and then run
your custom SQL. If changing the options of models or fields is not
enough, then you might have to get your hands dirty, and figure out
the name of the index with editor._constraint_names, but then you are
entering private API territory, and things might break on you after
upgrading Django.

Yet another alternative might be to upgrade to a version of Django
that's not past EOL, and use the more explicit support for indices
introduced in 1.11, but I have no idea how much easier it would make
to solve your problem. (You should consider upgrading regardless,
though.)

Good luck,

Michal