E012 is raised when ForeignKey is used by "_id" in an Index.

[James Cheese]

Looks to be an issue with the implementation in #28714 - issue found whilst upgrading from 2.0 to 2.2, but also occurs in latest 2.1.x.

To duplicate, create a compound index including the ID for a ForeignKey, eg:

class DataConcentrator(models.Model):
    #...

class ConcentratorHeartbeat(models.Model):
    #...
    class Meta:
        indexes = [
            models.Index(fields=["source_id", "-collected_at"]),
        ]
    #...
    source = models.ForeignKey(DataConcentrator, null=True, related_name="heartbeats", on_delete=models.CASCADE)

Expected behaviour:
No errors raised

Encountered behaviour:
Error raised on system check:

Performing system checks...

Unhandled exception in thread started by <function check_errors.<locals>.wrapper at 0x00000298392F3D08>
Traceback (most recent call last):
  File "C:\Workspace\sensor-analytics-tool\.pyenv\lib\site-packages\django\utils\autoreload.py", line 225, in wrapper
    fn(*args, **kwargs)
  File "C:\Workspace\sensor-analytics-tool\.pyenv\lib\site-packages\django\core\management\commands\runserver.py", line 117, in inner_run
    self.check(display_num_errors=True)
  File "C:\Workspace\sensor-analytics-tool\.pyenv\lib\site-packages\django\core\management\base.py", line 425, in check
    raise SystemCheckError(msg)
django.core.management.base.SystemCheckError: SystemCheckError: System check identified some issues:

ERRORS:
sensor_receiver.ConcentratorHeartbeat: (models.E012) 'indexes' refers to the nonexistent field 'source_id'.

System check identified 2 issues (0 silenced).

Current workaround is to just silence E012. Gets things running, but obviously not ideal.

[Mariusz Felisiak]

I agree that this behavior has changed in Django 2.1, but currently check is consistent with similar checks for index_together and unique_together. To use foreign keys in models.Index you can use field name, i.e.

indexes = [
    models.Index(fields=["source", "-collected_at"]),
]

[James Cheese]

That's fair - thanks for the clarification. Is it possible/worth dropping a note regarding the new system check into the 2.1 release notes, in case others hit the same issue? Admittedly, if nobody else has seen this after 6 months it's probably not a big deal, but I assume there'll be some other people jumping from the 1.11 LTS straight to 2.2 LTS that might encounter it.

[Simon Charette]

I think we should adjust the checks to allow both .name and .attname forms since the rest of the ORM allows both.

[zeynel]

I too agree that we should allow .attname usage in index_together, unique_together and indexes, since it is allowed to use .attname in other places such as order_with_respect_to, ordering.

[Mariusz Felisiak <felisiak.mariusz@…>]

In 6485a5f4:

Fixed #30409 -- Allowed using foreign key's attnames in unique/index_together and Index's fields.