latest() does not behave as expected for equal timestamps

[mstamat@…]

When applying latest() to a field where two or more entries have equal timestamps, the entry with the lowest id is returned. What one would assume is that in such a case the entry with the highest id is returned.

Real life example: I run a ticket system that has the requirement of only storing the date (and not the time) where the status of the ticket changes. When a ticket is opened it is marked as "New". There is a page in my ticket system that shows the "New" tickets: i.e. the tickets that have "New" as the status returned by latest(). However, those tickets that are processed within the same day will still appear in this page. This is caused because all the status change entries for each of these tickets are in the same day and latest() will return the one with the lowest id.

I attach a one-line patch that fixes the issue.

[mstamat@…]

fix for the behaviour of latest() when there are more than one entries that have the same "latest" timestamp

[Russell Keith-Magee]

You're assuming that IDs will be handed out sequentially. This isn't always going to be a valid assumption. On most databases with a small amount of data, it will be fine, but on certain databases, larger installs, or installs with lots of data that is getting deleted, it's becomes less tenable.

In short, ordering by id is a fallback because we have to have to have a field that we know will exist. It's not really something that should be optimized. If you _really_ need to rely on the ordering of objects that occur on the same date, you need to add something to your model that represents that order and doesn't have any ambiguity.

On a procedural note: patch with no tests == "Here are some bugs we think you should have". A patch without tests isn't going to get much attention.

[(none)]

Milestone post-1.0 deleted