View Issue Details

IDProjectCategoryView StatusLast Update
000697210000-005: Information ModelSpecpublic2022-06-20 12:03
ReporterZbynek Zahradnik Assigned ToJeff Harding  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Fixed in Version1.05.01 
Summary0006972: Confused about ReferenceAdded and ReferenceDeleted verbs in ModelChangeStructureDataType - are they usable at all?
Description

This may be just me not understanding it well, but here is the problem:

In 1.04 Part 5 Table 156 (ModelChangeStructureDataType Structure), we have ReferenceAdded and ReferenceDeleted verbs. The description of them both contains the text "The affected Node may be either a SourceNode or TargetNode.".
My problem is that this is too vague - for my use case, I think that I must know which of the two nodes it is. The description then proceeds with saying, for ReferenceAdded , "Note that an added bidirectional Reference is reflected by two changes." (and analogously for ReferenceDeleted).

Let's say I want to keep track on the client what are the forward references from Node1, so I would make a browse and store them, and subscribe to model change events. I would like to know when there can be a new or deleted forward reference from Node1. How can I do that? It seems to me that there is nothing in ModelChangeStructureDataType that allows me to detect the right event. What I am interested in are references added or deleted whose SourceNode is Node1 (and the TargetNode is irrelevant at that point). When such event occurs, I could re-browse Node1 to obtain the new set of references.

The way I read the spec, I may never receive such event, because if, let's say, a reference from Node1 to Node2 is added, the server may choose to set the affectedNode to TargetNode (Node2), and my code would not understand that this is a change that has anything to do with Node 1. For bidirectional references, the server will then send a second change, for the inverse reference. And it may choose to set the affectedNode to the SourceNode of the inverse reference, which would be Node2 again, so again my code would not detect this as being related to Node 1.

There is also a converse problem: If I am interested in forward references from Node1, for an added reference from Node0 to Node1 the server may choose to set affectedNode to TargetNode (Node1), and the client will be forced to rebrowse the Node1 even though it is not needed at that moment.

Note: Definitions of bidirectional/unidirectional are in 1.04 Part 3, 5.3.2. Attributes [of ReferenceType NodeClass].

TagsNo tags attached.
Commit Version
Fix Due Date

Activities

Zbynek Zahradnik

2021-06-15 16:01

developer   ~0014566

Last edited: 2021-06-15 16:04

Agreed on the meeting to expand "Note that an added bidirectional Reference is reflected by two changes." by

", i.e. one with ReferenceAdded verb and the affectedNode being the SourceNode, and the second with the ReferenceAdded verb and the affectedNode being the TargetNode."

And a similar change with the ReferenceDeleted verb.

Jeff Harding

2021-09-28 16:29

developer   ~0015053

Try to add to 1.05.0, else 1.05.1

Jeff Harding

2021-10-27 18:13

developer   ~0015234

Added clarifying text to the ReferenceAdded and ReferenceDeleted verbs to explain bidirectional references.

Jim Luth

2022-06-20 12:03

administrator   ~0016876

Agreed that this is published in 1.05.01.

Issue History

Date Modified Username Field Change
2021-05-29 09:46 Zbynek Zahradnik New Issue
2021-06-15 16:01 Zbynek Zahradnik Note Added: 0014566
2021-06-15 16:04 Zbynek Zahradnik Note Edited: 0014566
2021-06-15 19:10 Jim Luth Assigned To => Jeff Harding
2021-06-15 19:10 Jim Luth Status new => assigned
2021-09-28 16:29 Jeff Harding Note Added: 0015053
2021-10-27 18:13 Jeff Harding Status assigned => resolved
2021-10-27 18:13 Jeff Harding Resolution open => fixed
2021-10-27 18:13 Jeff Harding Fixed in Version => 1.05.01
2021-10-27 18:13 Jeff Harding Note Added: 0015234
2022-06-20 12:03 Jim Luth Status resolved => closed
2022-06-20 12:03 Jim Luth Note Added: 0016876