Type Coercion with Windows Azure Tables, and the Twitpocalypse

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 int with 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)!