Duplicate inverse attributes in JSON serialization

[hlg]

Consider a project modified through the low level interface. For inverse relations in such a project, with higher cardinality, the SharedJsonSerializer delivers multiple instances of each reference - one for each revision in which that references has existed. See the example below, where the inverse relation IfcRelAggregates.IsDecomposedBy has been existing for 5 revisions.

{ "_i": 132903,
  "_u": "76e8cec6-3d9c-48ae-b07a-664fe9787809",
  "_r": "8",
  "_t": "IfcSite",
  "_s": 1,
  "GlobalId": "1cwlDi_hLEvPsClAelBNnz",
  "_rOwnerHistory": {
    "_i": 132401,
    "_t": "IfcOwnerHistory"
  },
  "Name": "Default Site",
  "Description": "Description of Default Site",
  "_rIsDecomposedBy": [
    { "_i": 329053, "_t": "IfcRelAggregates" },
    { "_i": 329053, "_t": "IfcRelAggregates" },
    { "_i": 329053, "_t": "IfcRelAggregates" },
    { "_i": 329053, "_t": "IfcRelAggregates" },
    { "_i": 329053, "_t": "IfcRelAggregates" }
  ], ...
}

I don't understand whether this issue is triggered in the serializer or in the database layer and if the latter whether on storage or on access. It is easy to work around the issue by eliminating duplicates on the client side. But obviously it would be better to remove the duplicates before, so they don't consume bandwith, memory and potentially disk space.

[rubendel]

Hmm, could be an a lot of different places. Do you get the same with the SharedJsonStreamingSerializer?

[hlg]

Yes, it is the same with the streaming serializer.