orleans: Json serialization, references, wrong ordering

Using Json serialization when you have multiple references to the same object usually creates a graph such that the first time an object is encountered it has the properties and an $id which identifies that instance. Thereafter, in the JSON a $ref property is used to identify that pre-defined object and a reference is inserted.

I have a situation where the $ref comes before the definition of the object, which means that is being deserialized to null.

This is a real headscratcher, because I cant reproduce the same problem in isolation using a simpler object graph and JSON.NET. Butmy fairly complex grain state exhibits the problem every time.

Has anyone ever experienced this?

Below is a (snipped) copy of my JSON demonstrating the problem. You’ll notice 2 "$ref" : "5" that come before the definition of "$id": "5":

{
  "$id": "1",
  "$type": "Redacted.GrainSTateTypeName, Redacted.GrainAssembly",
  "Block": {
    "$id": "2",
    "$type": "Redacted.TypeName, Redacted.Assembly",
    "Terms": {
      "$type": "Redacted.TypeName.SubTypeName[], Redacted.Assembly",
      "$values": [
        {
          "$ref": "5"
        }
      ]
    },
    "Action": "Transition",
    "Driver": {
      "$id": "27",
      "$type": "Redacted.OtherTypeName, Redacted.Assembly",
      "Terms": {
        "$type": "Redacted.TypeName.SubTypeName[], Redacted.Assembly",
        "$values": [
          {
            "$ref": "5"
          }
        ]
      },
     [....snip...]
    "currentStateRecord": {
      "$id": "4",
      "$type": "Redected.TypeName.StateTypeName, Redacted.Assembly",
      "State": 1,
      "Terms": {
        "$type": "Redacted.TypeName.SubTypeName[], Redacted.Assembly",
        "$values": [
          {
            "$id": "5",
            "Name": "qty",
            "$type": "Redacted.TypeName.SubTypeName, Redacted.Assembly",
            "value": 10
          }
        ]
      }
   [...snip...]
   }
}

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Comments: 18 (18 by maintainers)

Commits related to this issue

Most upvoted comments

I suspect it will do. Its not the same change I made locally - which was to make those columns json, but given the conversation above, the use of text should be fine.

@veikkoeeva Thanks for the explanations 😃

What comes to the actual script design, it is open-ended on purpose so that if the users want to, they can modify the scripts (as explained in them)

This is probably a good argument for text values, as it will probably fit most users needs (efficient because no validation is done and the data is not altered so it will fix the de-serialization issue). I don’t know how the other users use it, but I guess in most of the case it is used as a black box and the main concern is that it works 😉

Users that have more complexe use cases can easily change the column type.

For MySQL the LONGTEXT type predates versions that had a native JSON type. I don’t know if it would be useful to change this format. Reading from https://dev.mysql.com/doc/refman/5.7/en/json.html sugggests JSON is stored in more compact form and queries to subelements are more effective

I would be careful about that, this is exactly why jsonb type is a problem!