Serialization Options With Azure DocumentDB

Tuesday, April 28, 2015

DocumentDBBehind the scenes, Azure’s DocumentDB uses Json.NET to serialize objects. Json.NET offers some flexibility in how serialization behaves through a number of serialization settings, but the DocumentDB SDK doesn’t expose these settings.

What if we want to change, say, the  NullValueHandling behavior to ignore null values?

Michalis Zervos offers one solution. Serialize objects using your own code then save the result as a document with the stream based APIs of DocumentDB. This approach gives you the ultimate control over when and how to serialize each object.

Another approach is to use the global default settings of Json.NET.

JsonConvert.DefaultSettings = () =>
{
    return new JsonSerializerSettings
    {
        NullValueHandling = NullValueHandling.Ignore
    };
};

Being global, you’ll want these settings to apply to all the documents saved into Azure, as well as any other serialization that might be happening in the same application. but it can turn this document:

{
  "Name": "Scott",
  "Medications": null,
  "Procedures": null,
  "id": "c15a4b48-bc7b-4440-a32b-88a9c345f705"
}

.. into this one:

{
  "Name": "Scott",
  "id": "e388eb16-de6f-4de6-9b11-851c2a67ef9e"
}

Comments
gravatar Brent Newbury Wednesday, April 29, 2015
My biggest annoyance with the serialisation was the lowercase "id" property that is required by DocumentDB. I had to pollute my POCOs with serialisation properties so that my Id property would be serialised/deserialised. I'm surprised this wasn't automatically handled.
gravatar Ryan CrawCour Wednesday, April 29, 2015
Thanks for the feedback! this is one of the items on the list of improvements we plan to make to the SDK, we just have not got to it yet. Please vote for it - http://feedback.azure.com/forums/263030-documentdb/suggestions/6422364-allow-me-to-set-jsonserializersettings and help get it higher up the priority list.
gravatar Bernhard Tuesday, May 5, 2015
I never understand why people seem so keen on these document DBs. Every time I do something, even the simplest little app eventually leads me down a path where I find I want to JOIN two tables to get the results, and I'd rather do that in SQL than C#. Maybe I've missed the back story to this - I've not read all your blog posts...yet! :)
gravatar Richard Tuesday, May 5, 2015
If you have to do joins, either a) your document db is not modeled correctly, or b) your problem domain requires a relational data model anyway. Document DBs excel at "put the thing in the bag, take the thing out of the bag". They're great for logging, caching and session state servers, for instance, where you will read and write in chunks. They're also useful on the operational side of web sites - think shopping cards and user preferences. At some point I suspect that many apps will come to use a hybrid approach. We don't need joins on the contents of our shopping carts, and we don't need transactional support either. But when we come to create an actual order from that shopping cart, where inventory, cost of goods, and A/R all have to get updated together in a transaction safe manner, that gets handled by an order entry service using a relational back end db. Reporting scenarios, where you will have complex queries, aggregations and calculations that are unknown at the time the db is designed will always be better served by a relational db. This isn't an either/or question.
Comments are closed.

My Pluralsight Courses

K.Scott Allen OdeToCode by K. Scott Allen
What JavaScript Developers Should Know About ECMAScript 2015
The Podcast!