QuerySet.order_by() should be chainable

[Joey Wilhelm]

I have a case where it would be very convenient to be able to call order_by() multiple times, appending to the order by clause with each successive call; i.e.,

foo = Model.objects.all().order_by('field1')
if bar:
    foo = foo.order_by('-field2')

Currently, the second call to order_by() explicitly overrides the previous order. This is not the behavior I would expect, as most (all?) other methods on a QuerySet are chainable.

If it is decided that chaining will not be allowed with order_by(), then I think that this fact should at least be documented. Had I not been printing out my connection's queries when I ran into this problem, it may have taken me some time to figure out exactly what was going on.

[Alex Gaynor]

having them just chainable by default would be backwards incompatible, so it really can't be done, however perhaps their could be a kwarg to tell order_by not to remove the previous ordering(reset=False perhaps?).

[Alex Gaynor]

FWIW the code changes needed would be VERY minimal once a good API is determined.

[Alex Gaynor]

patch that adds the proposed reset kwarg, backwards compatible

[Chris Beaven]

Bikeshedding: Explicitly setting reset=False seems weird (a default of True is the odd bit, I guess).

How about if it was append=True instead?

Agreed that if this ticket is wontfixed, the docs should at least be clarified.

[Alex Gaynor]

SmileyChris: bikeshed all you want, I let people who know how to design APIs do that :)

[anonymous]

To get around this until the patch lands, we currently have an ordering = [] set and as the orderings are picked up append to ordering. The final step is then qset = qset.order_by(*ordering).

[Malcolm Tredinnick]

No, the current behaviour is deliberate. The reason is that chaining for ordering would actually behave very counter-intuitively, since ordering is left-to-right sensitive in terms of "most significant" to "least significant". Things added after the initial ordering end up having almost no effect on the result, because the leading ordering terms dominate.

I don't see it as really common enough that the major ordering is going to be added in one place and minor tweaking of the far right, inisignificant terms will happen later that it's worth complicating the UI here.

A docs patch would be fine (in another ticket so that we can review it in isolation), but the current behaviour is quite intentional and it would be counter-productive to change it.

[Brillgen Developers]

I'd run into the same problem without an easy solution ...I pass around a lazy orderset in a structure hierarchy of classes and the possibility of adding an order_by secondary clauses for different cases.

@mtredinnick: I understand you may not have use cases where you can see the value in this, however providing an append=True option will neither bloat the code nor have a performance impact.

[Brillgen Developers]

Just to clarify futher:

Currently this works (and secondary order is very significant when you have lots of items matching on the first order key)
foo = Model.objects.all().order_by('field1', 'field2')

all that is being proposed is a fully backward compatible minor enhancement with no negative impact whatsoevery:

foo = Model.objects.all().order_by('field1')
.......
.......
if bar:

foo = foo.order_by('field2', append=True) # For use cases where the original order_by is not known...this again has no harm, and for people who don't need it don't need to use it!!

[Aymeric Augustin]

Please don't reopen a ticket closed by a core developer.

If you want to reverse a decision made by a core developer, you should write to the django-developers mailing-list.

Take a look at the contribution guidelines in the docs for more information. Thanks :)