I hope you're right, but my app design depends on since_id, and before I proceed further I want to be sure that I will not have to rebuild when this new format comes in.
On 26 March 2010 21:09, Ray Krueger <raykrue...@gmail.com> wrote: > I would think that this would make no difference for since_id. The > purpose of since_id is for us to the API "give me the data I need > that's happened since this id". Don't assume it's implemented as > "select * from tweets were id > since_id". :) > > > On Mar 26, 4:01 pm, Michael Bleigh <mble...@gmail.com> wrote: > > To those voicing concerns about since_id I believe the key word is > > that they will no longer be *sequential*, something entirely different > > from them no longer being *increasing*. Since ID is a core part of the > > Twitter API that I very much doubt will be in jeopardy from this > > change. Twitter devs feel free to back me up or refute me. :) > > > > On Mar 26, 4:41 pm, Taylor Singletary <taylorsinglet...@twitter.com> > > wrote: > > > > > Hi Developers, > > > > > It's no secret that Twitter is growing exponentially. The tweets keep > coming > > > with ever increasing velocity, thanks in large part to your great > > > applications. > > > > > Twitter has adapted to the increasing number of tweets in ways that > have > > > affected you in the past: We moved from 32 bit unsigned integers to > 64-bit > > > unsigned integers for status IDs some time ago. You all weathered that > storm > > > with ease. The tweetapoclypse was averted, and the tweets kept flowing. > > > > > Now we're reaching the scalability limit of our current tweet ID > generation > > > scheme. Unlike the previous tweet ID migrations, the solution to the > current > > > issue is significantly different. However, in most cases the new > approach we > > > will take will not result in any noticeable differences to you the > developer > > > or your users. > > > > > We are planning to replace our current sequential tweet ID generation > > > routine with a simple, more scalable solution. IDs will still be 64-bit > > > unsigned integers. However, this new solution is no longer guaranteed > to > > > generate sequential IDs. Instead IDs will be derived based on time: > the > > > most significant bits being sourced from a timestamp and the least > > > significant bits will be effectively random. > > > > > Please don't depend on the exact format of the ID. As our > infrastructure > > > needs evolve, we might need to tweak the generation algorithm again. > > > > > If you've been trying to divine meaning from status IDs aside from > their > > > role as a primary key, you won't be able to anymore. Likewise for usage > of > > > IDs in mathematical operations -- for instance, subtracting two status > IDs > > > to determine the number of tweets in between will no longer be > possible. > > > > > For the majority of applications we think this scheme switch will be a > > > non-event. Before implementing these changes, we'd like to know if your > > > applications currently depend on the sequential nature of IDs. Do you > depend > > > on the density of the tweet sequence being constant? Are you trying to > > > analyze the IDs as anything other than opaque, ordered identifiers? > Aside > > > for guaranteed sequential tweet ID ordering, what APIs can we provide > you to > > > accomplish your goals? > > > > > Taylor Singletary > > > Developer Advocate, Twitterhttp://twitter.com/episod > > To unsubscribe from this group, send email to twitter-development-talk+ > unsubscribegooglegroups.com or reply to this email with the words "REMOVE > ME" as the subject. > To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
