Hi John, Does that mean that status_ids may not be unique across all users? For example, one user could have status_id of 123 and another user can have status_id of 123 so you have to uniquely identify them by their user/status_id combination?
On Feb 11, 11:40 pm, John Kalucki <[email protected]> wrote: > In short, today, yes. Soon, no, but it might not matter. > > At the moment, status ids are strictly increasing. We can't keep generating > status ids from a single critical section forever though -- at some point > soon we'll have a loosely-coupled distributed id generation system and ids > will be k-sorted. Perhaps the most significant bits will be monotonically > increasing and the remainder of the precision will be opaque, and appear > random. With any luck, the monotonically increasing precision will map, > roughly, to time at a second resolution, so that the k-sorting will be > within a second quantum. This would allow collation order based on the 1 > second created_at and a collation order based on the most significant bits > will produce a similar, but not identical, ordering. Largely speculation. > > So, in the end, the date field remains the safest and the most future-proof > way to sort statuses. > > -John Kaluckihttp://twitter.com/jkalucki > Infrastructure, Twitter Inc. > > On Thu, Feb 11, 2010 at 2:36 AM, Quy <[email protected]> wrote: > > When I am sorting tweets, can I just do a simple sort DESC on > > status_id instead of the creation date? I assume status_ids are > > created sequentially going up so sorting on status_id would be more > > efficient than trying to sort on the created_at field.
