Question

I am working with an application where a .NET type derived from TableServiceObject being saved to Azure Table Storage (call it “Person”) has a collection of another entity (“events”). Of course, the collection property doesn’t save to Azure Table Storage.

What I would like to do is have a variable number of properties on a Person storage entity, and create a new property whenever necessary. For example, if Person1 has attended 1 event before, and attends a new event, my code needs to go create an “Event2” property for the Person1 entity, and save the pointer to the storage location of Event2 in that property. Person1 then has 2 “event” properties, but another entity in that table may have 10 (event1, event2, event3 … event10).

Because the Person class is mapped directly to the Azure Tables, which automatically creates a property for every public property in the class, I can’t find a way to dynamically add the Event2 property to this saved entity without creating a permanent property on my class, which I don’t want to do. Is there a way?

The purpose of wanting to store this “jagged” set of properties is to allow me to go get all the events a person has been to, without doing an entire scan on the partition where the events are stored.

Thanks!

Update: Smarx was correct – once I knew what to look for, it was easy to find this description of how to use the ReadingEntity and WritingEntity events in the Azure Table Service:
http://convective.wordpress.com/2009/12/30/entities-in-azure-tables/

Answer 1

I’m assuming you’re using .NET, because you mentioned classes mapping to entities in tables. Table storage itself has no schema, so this is a complete non-issue.

Using the WCF Data Services client library (what’s underneath Microsoft.WindowsAzure.Storage) without a schema is a bit tricky. Search for ReadingEntity and WritingEntity relating to table storage, and you’ll probably find what you need. Essentially, you need to hook these events and parse (or inject) the extra properties you want. People usually do this by creating a dictionary property to handle those “extra” properties and then read and write them when those events fire.

You might also check out http://www.lucifure.com/, an alternative client library that I have no experience with. I believe it addresses this limitation too: “Dynamic stashing via a dictionary, so you do not have to map every table property to a class member.”