About 2 weeks ago Microsoft released the new version of the Windows Azure Storage SDK, version 220.127.116.11. This version introduces a new way to work with Table Storage which is similar to the Java implementation of the SDK. Instead of working with a DataServiceContext (which comes from WCF Data Services), you’ll work with operations. Here is an example of this new implementation:
- First we initialize the storage account, the table client and we make sure the table exists.
- We create a new customer which inherits from TableEntity
- Finally we create a TableOperation and we execute it to commit the changes.
Taking a deeper look TableEntity
You’ll see a few changes compared to the old TableServiceEntity class:
- The ETag property was added
- The Timestamp is now a DateTimeOffset (much better for working with different timezones)
- 2 new virtual methods: ReadEntity and WriteEntity
By default, these methods are implemented as follows:
- ReadEntity: Will use reflection to get a list of all properties for the current entity type. Then it will try to map the values received in the properties parameter and try to map the values.
- WriteEntity: Will use reflection to get the values of each property and add all these values to a dictionary.
As you can see, both of these methods can come in handy if you want to do something a little more advanced. Let’s see how easy it is to create a new TableEntity which acts like a dictionary.
The following code overrides both the ReadEntity and WriteEntity methods. When reading the entity, instead of using reflection, the list of properties is simply stored as a Dictionary in the object. When inserting or updating the entity, it will use that Dictionary and persist the values to Table Storage. This new class also implementas the IDictionary interface and adds a few extra methods which make it easy to add new properties to the object.
Creating new entities
Ok so previously I created the Customer entity and added 2 customers. Now I want to be able to manage a bunch of information about this customer like the locations of the customer and the websites. The following implementation would even make it possible to declare the possible ‘content types’ at runtime. This means you could even extend your application without having to recompile or redeploy the application.
In this code I’m doing 2 things:
- Create a new entity to which I add the city and street properties (this represents the customer’s address)
- Create 2 new entities to which I add the url property (this represents the customer’s website)
The advantage here is that we can store all this information in a single partition (see how I’m using the customer’s name as partition key). And as a result, we can insert or update all this information in a batch transaction.
And with TableXplorer you can see the result:
Reading existing entities
Reading data with the DictionaryTableEntity is also very easy, you can access a specific property directly (as if the entity was a dictionary) or you could also iterate over all properties available in the current entity:
To get started simply grab DictionaryTableEntity.cs from GitHub and you’re good to go.