olosegres/jsona

Bug in deserialize: "included resources" data takes priority over "primary data"

coclav opened this issue · 1 comments

Hello,

I have found a bug in the deserialization where the "included resource" is kept, instead of the "primary data" for the same resource.

  • my payload is made of primary data of type box AND processes
{ 
  data: [ 
    { type: "box" }, 
    { type: "process" } 
  ]
}
  • I have the following relationships : box -> revision -> link -> process
  • my "box" in the primary data related to the process in the primary data

Now let's evolve our example (see the 2 "watch out" comments)

{
  "data": [
    {
      "id": "1",
      "type": "box",
      "relationships": {
        "revision": {
          "data": {
            "id": "1",
            "type": "revision"
          }
        }
      }
    },
    {
      "id": "1",
      "type": "process",
      "attributes": {
        "prop-1": "hello" // watch out : primary data has "prop-1"
      }
    }
  ],
  "included": [
    {
      "id": "1",
      "type": "revision",
      "relationships": {
        "link": {
          "data": {
            "id": "1",
            "type": "link"
          }
        }
      }
    },
    {
      "id": "1",
      "type": "link",
      "relationships": {
        "process": {
          "data": {
            "id": "1",
            "type": "process"
          }
        }
      }
    },
    {
      "id": "1",
      "type": "process",
      "attributes": {
        "prop-2": "prop2" // watch out, related data has prop-2 !
      }
    }
  ]
}

you can try it there : https://codesandbox.io/s/jsona-bug-deserialize-iq4owb

On deserialize i'm expecting the final object to have prop-1 and prop-2 to be ignored.

In this scenario above, the deserialization will retain the process object with "prop-2", i.e. the "included resource" and not the primary data object (with prop-1)

Screenshot 2022-07-06 at 14 34 19

The bug only starts to happen when there is 2 level of relationships in the related data ( for example if i had box -> revision -> process that would be fine) which is why i think it's a bug !

Hello,
thanks, there really were two cases using the wrong cache, respectively, the wrong data.
But in your case, I'm not sure that this is the best implementation, perhaps it would be better to merge the attributes.
But for now I fixed it as you described.

Update to version 1.10.1

Also note that you can switch to preferentially using data from the root object for building relationships using the preferNestedDataFromData option on the deserialize method