To duplicate, create a compound index including the ID for a ForeignKey,
eg:
{{{#!python
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/30409>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Comment (by felixxm):
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"]),
]
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/30409#comment:1>
Comment (by 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/30409#comment:2>
* type: Bug => Cleanup/optimization
* stage: Unreviewed => Accepted
Comment:
I think we should adjust the checks to allow both `.name` and `.attname`
forms since the rest of the ORM allows both.
--
Ticket URL: <https://code.djangoproject.com/ticket/30409#comment:3>
* status: new => assigned
* owner: nobody => zeynel
Comment:
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`.
--
Ticket URL: <https://code.djangoproject.com/ticket/30409#comment:4>
* has_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/30409#comment:5>
* version: 2.2 => master
--
Ticket URL: <https://code.djangoproject.com/ticket/30409#comment:6>
* status: assigned => closed
* resolution: => fixed
Comment:
In [changeset:"6485a5f450b3dc60e690c31a75e0e9574a896842" 6485a5f4]:
{{{
#!CommitTicketReference repository=""
revision="6485a5f450b3dc60e690c31a75e0e9574a896842"
Fixed #30409 -- Allowed using foreign key's attnames in
unique/index_together and Index's fields.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/30409#comment:7>