Here are some architectural information on dealing with disparate entity types with Windows Azure Table Storage.
For example you have an objective to store some kind of application entitlement information in Windows Azure table storage and to handle the information effectively, you have the following pair of entity distribution:
- An entitlement
- To handle entitlement you can have EntitlementEntity
- Zero or more associated transactions
- And for handling transection, you can have TransactionEntity
When you are going to add or update an entitlement, you can consider the following:
- Add or update an entitlement means adding or updating zero or more transaction entities
- It is also necessary to have add or update operation atomic
- Using Batch update maintain atomic operations
- You don’t necessarily know if an entitlement or transaction entity exists in table storage before you add a create or update operation for that entity to the context as a batch, so you need to query for each entity that’s part of the batch operation before deciding whether to add\update.
- There is significant amount of additional overhead to keep overall operation atomic and not having the batch operation fail because of a not found or conflict problem.
To handle above situation here are some expert tips:
- The pattern to store multiple kinds in the same table is to have a property with kind (which can be used for easy checks on client end) and also store it as part of the row key.
- Inserting/Updating multiple entity types in a single Entity Group transaction (EGT) is straightforward. It is also straightforward to retrieve just one kind.
- However, to retrieve multiple kinds in a single result set, you would need to use the union type.
- There is another options you can use by parsing the xml entity in ReadingEntity event.
As you may know upsert is not available yet with Windows Azure Storage API however keep an eye at Windows Azure Storage Team announcement and you may see some update on this regard.