Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Sorting by occurred_on/id is more logical than occurred_on/updated_at #18

KieranP opened this Issue May 20, 2009 · 2 comments


None yet
2 participants

KieranP commented May 20, 2009

When someone edits an item that was made on the same date as another item, it gets repositioned higher in the list.

For people who want to structure their data, to compare against bank accounts, it becomes tricky when they edit an item.


Using that patch, it sorts by occurred_on, and then by id, to maintain the order people add items.


jamis commented May 26, 2009

I'm always uncomfortable with sorting by id, since it's not formally defined as being a monotonically increasing value. I think it might be better to sort events by (occurred_on, created_at), since created_at has, by definition, an order defined for it.

Also, the sql-nazi in me is cringing, slightly, at the thought of performing a query like that without having the full sort criteria in the index. Given, though, that the number of events having the same occurred_on value will be small, it's probably going to fine without including created_at (or id, if you can convince me).

KieranP commented May 28, 2009

Sure, created_at sounds like a better column to sort by. Not sure what you mean by "without having the full sort criteria in the index", however the number of events on the same day is not small. Using a joint account, I can see upward of 15 or more sometimes and when it comes to compare with bank accounts, its a hassle if the bottom is at the top is at the top because I edited it.

Any you could always provide an options of switching between sorting by creation, and sorting by updated at if you want to maintain the current functionality.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment