{{{
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(null_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']
}}}
fails with {{{ 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/29538>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* cc: wilhelmhb (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/29538#comment:1>
* stage: Unreviewed => Accepted
Old description:
> 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(null_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']
> }}}
> fails with {{{ 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.
New description:
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.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/29538#comment:2>
* status: new => assigned
* owner: nobody => Alexandre Laplante
Comment:
Started working on a fix.
--
Ticket URL: <https://code.djangoproject.com/ticket/29538#comment:3>
* has_patch: 0 => 1
Comment:
[https://github.com/django/django/pull/10146 PR] Looking for feedback on
this patch.
--
Ticket URL: <https://code.djangoproject.com/ticket/29538#comment:4>
* needs_better_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/29538#comment:5>
* cc: colons (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/29538#comment:6>
Comment (by 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
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/29538#comment:7>
Comment (by Mariusz Felisiak):
#33678 was a duplicate for functions in related `Meta.ordering`.
--
Ticket URL: <https://code.djangoproject.com/ticket/29538#comment:8>
Comment (by 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
--
Ticket URL: <https://code.djangoproject.com/ticket/29538#comment:9>
* cc: Eduardo Rivas (added)
* needs_better_patch: 1 => 0
Comment:
[https://github.com/django/django/pull/15666 PR]
--
Ticket URL: <https://code.djangoproject.com/ticket/29538#comment:10>
* owner: Alexandre Laplante => Eduardo Rivas
--
Ticket URL: <https://code.djangoproject.com/ticket/29538#comment:11>
* needs_tests: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/29538#comment:12>
* needs_tests: 1 => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/29538#comment:13>
* stage: Accepted => Ready for checkin
--
Ticket URL: <https://code.djangoproject.com/ticket/29538#comment:14>
* status: assigned => closed
* resolution: => fixed
Comment:
In [changeset:"2798c937deb6625a4e6a36e70d4d60ce5faac954" 2798c937]:
{{{
#!CommitTicketReference repository=""
revision="2798c937deb6625a4e6a36e70d4d60ce5faac954"
Fixed #29538 -- Fixed crash of ordering by related fields when
Meta.ordering contains expressions.
Thanks Simon Charette for the review.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/29538#comment:15>
Comment (by 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/29538#comment:16>
Comment (by Mariusz Felisiak):
Replying to [comment:16 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+.
--
Ticket URL: <https://code.djangoproject.com/ticket/29538#comment:17>