Use custom JsonSerializerSettings

[galvesribeiro]

Since the State payload is serialized as object, it goes just fine inside the StateEntity in CosmosDB as you may see in the following sample:

{
    "id": "00000000-0000-0000-0000-000000000000_GrainReference=00000000000000000000000000000000030000004e9c6618",
    "GrainType": "Orleans.CosmosDB.Tests.Grains.TestGrain",
    "State": {
        "Data": [
            "Test 0",
            "Test 0",
            "Test 0"
        ]
    },
    "_etag": "\"0000db02-0000-0000-0000-5a66a9550000\"",
    "_rid": "2UIfAKJEnwACAAAAAAAAAA==",
    "_self": "dbs/2UIfAA==/colls/2UIfAKJEnwA=/docs/2UIfAKJEnwACAAAAAAAAAA==/",
    "_attachments": "attachments/",
    "_ts": 1516677461
}

However, when we deserialize the State field back, it comes as a JObject because Json.Net doesn't know the proper type to deserialize to. That can be fixed if we use a custom JsonSerializerSettings object when initializing the DocumentClient and tell it to include the Type to the object serialized. I tried that, and when sending back the document to the database with that settings applied, the sproc parameters are all undefined.

To workaround the deserialization issue, I introduced the workaround here.

Just logging this issue so we can investigate how to properly use the JsonSerializerSettings and avoid the call to JObject.ToObject<T>() when deserializing the state.

[bytelabsco]

I took at look at this, and was really struggling to find the right combination of settings to get this to work.

Previously I was able to supply JsonSerializerSettings to the DocumentClient with TypeNameHandling set to all. However, doing this while using stored procedures resulted in the parameters always being undefined within the stored procedure. I also tried TypeNameHandling.Objects and TypeNameHandling.Auto with a little more success. In the latter 2 cases, the $type property was properly saved with the document. But, when deserializing, the $type information seemed to be getting ignored, and the resulting State property would always be a JObject.

I also tried setting MetadataPropertyHandling to ReadForward, thinking the $type property wasn't coming in first, but to no avail.

[galvesribeiro]

Yeah, that is precisely the behavior I had... If we don't find out, I'll open a ticket on Azure support team as DocDB package isn't OSSed unfortunatelly.

[COCPORN]

I opened a pull request to remedy this situation: #21

[galvesribeiro]

Fixed on #21