Take indexes into account in inspectdb command

[Akshesh Doshi]

Currently, inspectdb command takes into account existing tables (via models.Model), columns (via models.Field) and unique constraints (via unique_together) while inspecting the db. It would be helpful to take into account the existing indexes (via models.Index) on the table as well.

[Akshesh Doshi]

I have an almost ready patch for this feature.

[Akshesh Doshi]

PR: ​https://github.com/django/django/pull/7083

[Tim Graham]

The complication is that models.Index might not match the type of the index. As noted on the PR, I'd think we'd at least want to add a comment in the output if the type of the introspected index doesn't match.

[Claude Paroz]

Another question is about index_together vs models.Index. Are we going to keep both way of defining multicolumn indexes? Should one be privileged over the other? Depending on the answer, the patch might have to be adapted.

[Akshesh Doshi]

Some steps have been taken to deprecate index_together, see - https://code.djangoproject.com/ticket/27064
I created a ticket to track deprecation of index_together here - https://code.djangoproject.com/ticket/27236

[Pavel White]

PR: ​https://github.com/django/django/pull/11944

This PR:

• [x] Add db_index field param

Next PR:

• [ ] Add Meta.indexes support

[Mariusz Felisiak]

This ticket is about adding support for Meta.indexes to the inspectdb not about the db_index option. Mainly because it can be hard to ensure that an inspected index is exactly the same as an index created by Django (type, ordering, operator classes, fillfactor etc.). That's why we accepted a ticket to support Meta.indexes where these options may be included.

[Mariusz Felisiak]

​PR

[David Wobrock]

I started looking a bit into this ticket, and one of the issues I encounter is that we don't get back most parameters needed to reconstruct the Index class.
With the current introspection.get_constraint implementations, we will mainly be able to re-create the fields and order. We have some information, but:

• few information about expressions (we could mainly infer that we used expressions if no columns are specified for that index)
• nothing about opclasses (even if postgresql specific)
• nothing about db_tablespace
• nothing about condition
• nothing about include (even if postgresql specific)

And I strongly suspect nothing either on buffering, fillfactor and others for postgresql.indexes :/

The best I can think of would be to

1. add a new introspection method for each database, that would allow to fetch the CREATE INDEX SQL statement from a tablename+indexname (if this is possible on all supported databases)
2. from the SQL statement, try to reverse engineer it in a best effort manner and extract all given elements. Some elements will be very difficult to express in Django again (like expressions), so we probably should display a comment with the original CREATE INDEX

How does that sound? (to me a bit brittle admittedly)

An even simpler approach could be to only handle fields+order, and always add the CREATE INDEX statement as a comment for the user then to manually convert it to the right Index parameters.