Upgrade Storage"Related" call-back sufficiently descriptive?
The event notification for a creating a "related" connection between two items seems to require some reading between the lines. Specifically:
- The event signature is just:
event="modify"
type="item"
ids=[12874, 1814]
extraData=... content of 1st object prior to related change... ... content of 2nd object prior to related change ...
- The event signature for deleting a "related" connection is essentially identical to the signature for adding a "related" connection.
As near as I can tell, the only way to determine that an event implies creation or deletion of a relationship is that it is a "modify", "item" that has exactly two arguments in the ids array. To distinguish between an "add related" and a "delete related", you need to see if ids[1] matches one of the ids in extraData[0].seeAlso. If there is a match, then it's a "delete related" (no match --> "add related").
The isn't so bad, as long as the "modify", "item", ids[xxx,yyy] signature is absolutely unique to "related". On the other hand, a more explicit event signature might be good (no ambiguity, easier to parse).
- The event signature is just:
event="modify"
type="item"
ids=[12874, 1814]
extraData=... content of 1st object prior to related change... ... content of 2nd object prior to related change ...
- The event signature for deleting a "related" connection is essentially identical to the signature for adding a "related" connection.
As near as I can tell, the only way to determine that an event implies creation or deletion of a relationship is that it is a "modify", "item" that has exactly two arguments in the ids array. To distinguish between an "add related" and a "delete related", you need to see if ids[1] matches one of the ids in extraData[0].seeAlso. If there is a match, then it's a "delete related" (no match --> "add related").
The isn't so bad, as long as the "modify", "item", ids[xxx,yyy] signature is absolutely unique to "related". On the other hand, a more explicit event signature might be good (no ambiguity, easier to parse).
I know we have the Developers section here, but we'd prefer to keep the internals stuff over on that list.
Thanks.