Today I read some news about the pending Twitpocalypse. If you haven’t heard, Twitter is rapidly approaching a rollover point (much like the Y2K scare) where status IDs will reach values higher than what can be stored in a 32-bit signed integer. The worry is that Twitter clients are storing status IDs in 32-bit integers and will malfunction when the rollover happens.
One of my projects, Botomatic, is actually broken in this way. I rolled my own Twitter API client, and I parsed the status IDs into 32-bit integers. For the most part, the fix was trivial; just replace
long. There was one part of the fix, however, that worried me. I was storing some of those 32-bit integers in Windows Azure Table storage. What would happen when I updated the code to use 64-bit integers instead?
As you probably know, Windows Azure stores entities as a collection of properties and typed values. That means that going from a 32-bit integer to a 64-bit integer is a real change. Fortunately, the ADO.NET Data Services client library handles this type coercion quite nicely. All I did was modify my classes to use
longs instead of
ints. When I store a new entity, the numeric value gets stored as a 64-bit integer. When I retrieve an old entity, the value comes back as a 32-bit integer but gets nicely coerced into a 64-bit integer on the client.
In the end, the conversion turned into a complete non-event. Twitpocalypse averted (at least for Botomatic)!