Enable using an empty order_by() to disable implicit primary key ordering in first()

[Lily]

As discussed in ​https://github.com/django/new-features/issues/71, update the interaction between order_by and first to enable this behaviour:

# Existing
MyModel.objects.first()  # first, ordered by `pk`
MyModel.objects.order_by("pk").first()  # as above
MyModel.objects.order_by("name").first()  # first, ordered by `name`

# New
MyModel.objects.order_by().first()  # first, but in whatever order the database returns it

This will interact with ​default orderings (`Meta.ordering`), which will need some careful handling.

[Jacob Walls]

For folks checking the forum thread, when Tom Carrick summarized the options discussed ​here, this was "option 2", to which I did not see specific objections afterward.

---

This will interact with ​default orderings (Meta.ordering), which will need some careful handling.

I think that looks like this:

django/db/models/query.py

@@ -1135 +1135 @@
 
     def first(self):
         """Return the first object of a query or None if no match is found."""
+        # RemovedInDjango70Warning: replace with:
+        # if self.ordered or not self.query.default_ordering:
         if self.ordered:
             queryset = self
         else:
+            if not self.query.default_ordering:
+                warnings.warn(..., RemovedInDjango70Warning, skip_file_prefixes=django_file_prefixes())
             self._check_ordering_first_last_queryset_aggregation(method="first")
             queryset = self.order_by("pk")
         for obj in queryset[:1]:
@@ -1148 +1152 @@
 
     def last(self):
         """Return the last object of a query or None if no match is found."""
+        # RemovedInDjango70Warning: replace with:
+        # if self.ordered or not self.query.default_ordering:
         if self.ordered:
             queryset = self.reverse()
         else:
+            if not self.query.default_ordering:
+                warnings.warn(..., RemovedInDjango70Warning, skip_file_prefixes=django_file_prefixes())
             self._check_ordering_first_last_queryset_aggregation(method="last")
             queryset = self.order_by("-pk")
         for obj in queryset[:1]:

tests/queries/test_qs_combinators.py

@@ -416 +416 @@
         base_qs = Author.objects.order_by()
         qs1 = base_qs.filter(name="a1")
         qs2 = base_qs.filter(name="a2")
-        self.assertEqual(qs1.union(qs2).first(), a1)
+        self.assertEqual(qs1.union(qs2).order_by("pk").first(), a1)
 
     def test_union_multiple_models_with_values_list_and_order(self):
         reserved_name = ReservedName.objects.create(name="rn1", order=0)

I think this will need a deprecation (notice the edited test). We will be enforcing some more explicitness for users who must to clear an ordering for the sake of doing a union but then need to add it back to retain the prior behavior of first(), but I think that trade-off is worth it.

[Nilesh Pahari]

Just to confirm -- this ticket implements the deprecation step by adding a 'RemovedInDjango70Warning' , and the actual behavior change (disabling the implicit pk ordering) is intended for Django 7.0. Please let me know if I’m missing anything.

[Nilesh Pahari]

PR: ​https://github.com/django/django/pull/20458 (added deprecation warning)

[Jacob Walls]

Update: the union() stuff mentioned above turned out to be a symptom of a separate bug:

Default orderings weren't applied after a union(), due to the particular way that clear_ordering(force=True, clear_default=False) doesn't actually reset QuerySet.default_ordering back to True; it must be done manually. (A call to order_by() with no args does that manually.)

I segregated out Nilesh's fix for the union() behavior into a separate commit.

Then, we were able to do the primary fix for the order_by() <--> first() interaction without any unexpected behavior changes.