first() method has ambiguous naming, and is unintuitive at first glance

[natehalsey]

Today my team at Top Hat ran into an issue while using ormar. We intended to first sort the data in our table by a column that wasn't the primary key and then return the first result.

We went with the approach of using first as so: query = Model.objects.order_by(Some_Data.desc()).first()

This of course, didn't work. first() sorts by primary key and returns the first result. This is intended, and outlined in the docs, but the naming for this method is a little ambiguous, and the bug we were seeing wasn't recognizable at first glance.

You can definitely use other methods (limit(1, limit_raw_sql=True) comes to mind), but we were wondering if anyone else ran into this issue, or if the team had plans to change this method in any way.

One suggestion I have is to have the ability to pass arguments to give the particular ordering, and expanding it from just ordering on the primary key.

Thank you!

Edit: After looking around a bit this is fixed/changed as of 0.10.23. I think the docs should be updated to reflect this as well. 😄

[collerek]

Hi,

Yep was about to add that it now respects the ordering you provide but only on the main/parent model.

It is implemented like this in order to be consistent with limit/offset queries where it is difficult to get n first parent models when you order by child model (it's done in a subquery). Since each parent model can have 0 <-> infinity child models there is no way to reliably assess the number of rows required to get n first parent model without a second db call, which we want to avoid.

We thought about using distinct there so you can filter by children, but in some backends distinct changes the order (it's not guaranteed), so it cannot be used for reliable ordering.