Query Expression in ordering of a related object fails

[wilhelmhb]

Since 2.0, according to the doc (​https://docs.djangoproject.com/en/2.0/ref/models/options/#ordering), we can use QueryExpression objects in the Model.Meta.ordering field.
Using:

from django.db import models

class Musician(models.Model):
    first_name = models.CharField(max_length=50)
    last_name = models.CharField(max_length=50)
    instrument = models.CharField(max_length=100, null=True, blank=True)

    class Meta:
        ordering = [models.F('instrument').asc(nulls_last=True)]

class Album(models.Model):
    artist = models.ForeignKey(Musician, on_delete=models.CASCADE)
    name = models.CharField(max_length=100)
    release_date = models.DateField()
    num_stars = models.IntegerField()

    class Meta:
        ordering = ['artist']

>>> Album.objects.all()
...
TypeError: 'OrderBy' does not support indexing

When reaching ​https://github.com/django/django/blob/master/django/db/models/sql/compiler.py#L669, the compiler tries to use the related model, but at line 679, item can be an OrderBy object. Thus the failure.

[Alexandre Laplante]

Started working on a fix.

[Alexandre Laplante]

​PR Looking for feedback on this patch.

[Mariusz Felisiak]

After 8c5f9906c56ac72fc4f13218dd90bdf9bc8a248b it crashes with:

django.core.exceptions.FieldError: Cannot resolve keyword 'instrument' into field. Choices are: artist, artist_id, id, name, num_stars, release_date

[Mariusz Felisiak]

#33678 was a duplicate for functions in related Meta.ordering.

[Simon Charette]

If anyone is interested in addressing this ticket there's a possible implementation detailed in https://code.djangoproject.com/ticket/33678#comment:3

[Eduardo Rivas]

​PR

[Mariusz Felisiak <felisiak.mariusz@…>]

In 2798c937:

Fixed #29538 -- Fixed crash of ordering by related fields when Meta.ordering contains expressions.

Thanks Simon Charette for the review.

[a-p-f]

Sorry for my ignorance, but is there a simple way for users to see, from this page, which minor versions of Django have received this patch? I followed the link to the github commit page, and from what I could tell there, the fix was implemented in 4.1. That doesn't tell me, however, if the commit was cherry-picked into any other branches.

At first I had assumed that since 3.2 was the latest LTS release, it would receive this fix. I upgraded to 3.2.18, though, and this bug isn't fixed. Looking closer at Django's docs, I see that 3.2 is only in extended support, and this bug does not qualify for extended support. Fair enough. I just think it would help developers to make it clear which of the current versions have received a given fix.

[Mariusz Felisiak]

Replying to a-p-f:

Sorry for my ignorance, but is there a simple way for users to see, from this page, which minor versions of Django have received this patch? I followed the link to the github commit page, and from what I could tell there, the fix was implemented in 4.1. That doesn't tell me, however, if the commit was cherry-picked into any other branches.

At first I had assumed that since 3.2 was the latest LTS release, it would receive this fix. I upgraded to 3.2.18, though, and this bug isn't fixed. Looking closer at Django's docs, I see that 3.2 is only in extended support, and this bug does not qualify for extended support. Fair enough. I just think it would help developers to make it clear which of the current versions have received a given fix.

You can click commit (2798c937deb6625a4e6a36e70d4d60ce5faac954) which fixed this issue and check tags, 4.1a1 so it's fixed in Django 4.1+.