Phil Pirozhkov

@andyw8 Your writing skills are evidently superior to mine, so who would be better than you to send a PR?

Note to future self: it's possible to check/harvest for usage examples in https://github.com/eliotsykes/real-world-rails, https://github.com/pirj/real-world-rspec (slightly more up to date, but fewer Rails repos). From Rails Guides: > Active Support has...

@rubocop/style-guide-editors ping

I'd love to see a confirmation that this order is followed by [real-world Rails apps](https://github.com/eliotsykes/real-world-rails).

What do you think of a soft wording for the guideline? e.g. > Use the default order of resourceful actions in your controller. Feel free to intermingle them with additional...

Af far as I'm aware, `created_at` maps to `TIMESTAMP` DB type which has microsecond precision on Postgres and **milli**second on MySQL *by default*. For MySQL [Rails 6 is adding `precision:...

Again, I see what you mean, but again, for those bulk insert operations ordering by a tuple of `created_at` + `id` would result in exactly the same problems as just...

Point is that the chronological order is just one of the possible use cases. Any other column combination might be a better option can be more desirable depending on business...

The current wording > Use a timestamp column to order chronologically suggests ordering by `created_at` instead of the default ordering by id in the case when something is expected to...

@mockdeep Sounds reasonable. What makes `id` better for pagination than `created_at` specifically is that it is unique, while `created_at` is not. If the order of records returned by the same...