suggest-index command does not recognize some index definitions

[sevdog]

VS Code version

None

OS

Ubuntu 24.04

Steps to reproduce

The suggest-indexes command seems to not recognize the following indexes:

• primary key, also filtering by pk= and id= (in default model configuration, without any PK ovedrride) is not recognized as the same filter (pk is just an alias of whatever the primary key field is)
• fields with db_index=True (including foreign-keys)
• unique fields unique=True (because a unique constraint involves an index)
• UniqueConstraints

Sample models.py (minimized)

class AModel(models.Model):
    field = models.IntegerField()

class SimpleModel(models.Model):
    unique_field = models.IntegerField(unique=True)
    foreign_key = models.ForeignKey(AModel, db_index=True)
    other_field = models.IntegerField()

    class Meta:
        constraints = [models.UniqueConstraint(fields=('foreign_key', 'other_field'), name='uc')]

[FROWNINGdev]

Fixed on main in 55ab9f8 — all four points, thank you.

Your list was accurate, and one item underneath it turned out to explain most of the rest: the parser truncated any multi-line class Meta value to a bare [. So constraints = [ … ] written across lines was invisible to every consumer, not just this one. Regenerating the golden snapshots showed the same truncation on wagtail, zulip, saleor and django-cms.

What now counts as already indexed, so no proposal is made:

• the primary key — and pk is folded onto the real primary-key column, so filter(pk=…) and filter(id=…) are one lookup with one count rather than two rows;
• db_index=True;
• unique=True;
• ForeignKey / OneToOneField, which Django indexes itself unless you pass db_index=False;
• Meta.unique_together and Meta.constraints with UniqueConstraint — both the list and the tuple spelling of fields=, since your example uses the tuple;
• the leading column of any composite index, which a B-tree does answer on its own.

One deliberate non-change, in case it looks like a miss: given your sample and a query filtering on both columns, the composite proposal disappears but a single-field proposal on other_field remains. A B-tree on (foreign_key, other_field) cannot serve a lookup on the trailing column alone, so that suggestion is real. It is asserted in the tests so nobody "fixes" it later.

There is also a new already_indexed key in the JSON output. Without it, a hot field with no proposal looks identical to the analyzer having missed the usage — which is how this bug stayed quiet.

Worth noting: @RinZ27 opened #61 against this issue independently and had diagnosed the same Meta truncation. Both of you are credited in the changelog and the roadmap.

Ships in the next release.