Opened 16 years ago

Closed 16 years ago

Last modified 16 years ago

#9208 closed (wontfix)

latest() does not behave as expected for equal timestamps

Reported by: mstamat@… Owned by: nobody
Component: Database layer (models, ORM) Version: dev
Severity: Keywords: latest
Cc: Triage Stage: Unreviewed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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.

Attachments (1)

query.py.diff (386 bytes ) - added by mstamat@… 16 years ago.
fix for the behaviour of latest() when there are more than one entries that have the same "latest" timestamp

Download all attachments as: .zip

Change History (3)

by mstamat@…, 16 years ago

Attachment: query.py.diff added

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

comment:1 by Russell Keith-Magee, 16 years ago

Resolution: wontfix
Status: newclosed

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.

comment:2 by (none), 16 years ago

milestone: post-1.0

Milestone post-1.0 deleted

Note: See TracTickets for help on using tickets.
Back to Top