Erick T
Erick T

Reputation: 7449

Using the WCF Data Services client for Azure Table Storage - storing graphs of objects

I am working with Azure Table storage using the .NET API (TableServiceContext, WCF Data Service, etc). I have a simple graph of objects that I want to save to the table store. In the service context class, I have the following code.

_TableClient.CreateTableIfNotExist("AggRootTable");
this.AddObject("AggRoots", model);
foreach (var related in model.RelatedObjects)
{
    this.AddRelatedObject(model, "RelatedCollection", related);
}
this.SaveChanges();

I have used this style of code in WCF Data Services via EF and a SQL Server, but it doesn't work against Azure Tables. I would not expect it to, as there aren't real relationships between tables in Azure. However, the methods are there. Does anyone know how to use AddRelatedObject, AddLink, etc in the context of Azure Tables? Or can suggest approaches to storing object graphs in general? I haven't been able to find any docs, and Google hasn't been helpful.

Thanks, Erick

Upvotes: 1

Views: 845

Answers (2)

Mark Seemann
Mark Seemann

Reputation: 233170

The Table Storage Service is generally not a good place to store entire object graphs, since there's a size limit (of 1 MB, IIRC) on each row/entity. Obviously, if you know that your object graphs will never be large, you may not care...

A good alternative is often to store a serialized graph in Blob Storage. However, you must have a strategy for how to handle versioning.

Upvotes: 1

Igorek
Igorek

Reputation: 15850

You can't. ATS does not support relationships. There are many non-working methods available due to it using data services API.

What you can do, however, is store the full object tree in a single table. Not sure if this will work for your design/architecture

also, it is a bad idea to keep calling CreateIfNotExists before every write operation. First, you pay extra for transactions that occur for the round-trip, second the call is not instantaneous and will slow down your writes. just precreate the tables before deployment or during roles start.

Upvotes: 1

Related Questions