Twitter's Snowflake Project To Update Tweet IDs Really Is More Like A Blizzard Now

Next Story

T-mobile myTouch 3G Froyo update now rollin' out

Last week, we noted that Twitter was on the verge of executing their long-in-the-making Snowflake project. Basically, this was a necessary step to switch up the way tweet IDs are handled due of Twitter’s move from MySQL to Cassandra for their database infrastructure. Twitter clearly realized that the switch-over might be a little bumpy, and that’s why they started alerting third-party developers about it months ago. But it turns out it’s even more bumpy than they realized. And that’s why the transition hasn’t happened yet. And won’t for a while.

A post today by developer advocate Matt Harris in the Twitter Development Talk Google Group outlines what is going on. It’s a bit technical, and if you’re a developer, you should obviously read the whole thing. It boils down to this: some programming languages, notably JavaScript, cannot support numbers with more than 53 bits. That’s a problem since Snowflake is going to create tweet IDs that are 64 bit unsigned integers.

Writes Harris:

To allow javascript and JSON parsers to read the IDs we need to include a string version of any ID when responding in the JSON format. What this means is Status, User, Direct Message and Saved Search IDs in the Twitter API will now be returned as an integer and a string in JSON responses. This will apply to the main Twitter API, the Streaming API and the Search API.

So, if you have developed your Twitter app using JavaScript, you need to update your code to read this string version of the tweet ID instead of the integer version. In other words, a lot of developers are likely going to have to alter their code to keep things kosher.

Luckily, you have some more time. Harris notes that this coming Friday (October 22), they will start placing string versions of tweet IDs in the API. On November 4, the plan is then to activate Snowflake, but limit tweet IDs to 41 bits. But on November 26, these IDs will go longer than 53 bits, so you’ll need to have your updated code in place by then.

It’s sort of like a mini Twitpocalypse of sorts. Or maybe a Twlizzard? Third-party Twitter developers: be sure to check your code.

[photo: flickr/sarah ackerman] [thanks Alex]

blog comments powered by Disqus