Is DiagramLinks.ConnectorID in VBScript read/write

[Paolo F Cantoni]

The Documentation says:

Code: [Select]

DiagramLinks Attributes

ConnectorID Long Notes: Read/Write The ID of the associated connector.
It is read-write, but under VBScript, it doesn't appear to be.  We have shown that if a change is attempted to ConnectorID, the whole Update (for example, IsHidden, Geometry etc.) will fail.  But if the ConnectorID change is not present (commented out), the rest of the change succeeds.

Can anyone confirm?  (FWIW, it's an .EAPX - Jet4 file)

TIA,
Paolo

[Eve]

From what I can see, if you change the ConnectorID or DiagramID it will add or update the record relating to the new pair. It won't change the existing record relating to the old pair.

[Paolo F Cantoni]

From what I can see, if you change the ConnectorID or DiagramID it will add or update the record relating to the new pair. It won't change the existing record relating to the old pair.

• I would have thought that if the InstanceID was the same, it should be an in-situ update
• There is NO new pair in this case.  We are re-pointing from one connector to another.

Paolo

[Eve]

The API update is acting on a DiagramID/ConnectorID pair. What I'm saying is that you can't re-point the diagram link via the API.

There IS a new pair. Whatever DiagramID and ConnectorID it has will be a new pair.

From what I can see, it will either replace the diagramlink information that already exists for the target connector id, or it will create a new one.

[Paolo F Cantoni]

The API update is acting on a DiagramID/ConnectorID pair. What I'm saying is that you can't re-point the diagram link via the API.

There IS a new pair. Whatever DiagramID and ConnectorID it has will be a new pair.

From what I can see, it will either replace the diagramlink information that already exists for the target connector id, or it will create a new one.

As far as we could see - with direct, live DB queries if we just changed the ConnectorID, NO new diagramlinks were created.

In my view the API is suspect.

Nowhere that I could see was this behaviour even implied!

Paolo

[qwerty]

Remember that in former EA versions diagramLinks were only created for manipulated connectors. Only recent (since V8 or so) create diagramLinks in all cases. There (might) be dragons.

q.

[Paolo F Cantoni]

Remember that in former EA versions diagramLinks were only created for manipulated connectors. Only recent (since V8 or so) create diagramLinks in all cases. The (might) be dragons.

q.

This is my thinking...  That's why the current behaviour is anomalous. 

The Instance_ID identifies WHICH diagram link is being manipulated (we know so because the SQL Queries need it).  If I change either (or even both) ConnectorID or DiagramID, but not the Instance_ID, then I'm manipulating Where (DiagramID) and How (ConnectorID) I want the specific link to appear.

If it was just a doublet (Tuple of ConnectorID, DiagramID) then why introduce Instance_ID?  To me, it seems the whole process is flawed.

As an aside, after I'd posted the original post. I thought "Hold your horses, Batman!  You've done this before..."  So I went searching through my VBA code (in this case in Excel) only to find we'd done it via SQL statements!  So we've done the same for VBScript.

As usual, I'd like to see a rationale for the current mechanism.

Paolo

[Eve]

I've only looked as far as seeing that Instance_ID is not used by the API. It reads like it Instance_ID didn't exist when it was written.

I don't know about rationale, but at least this way it doesn't need to try to avoid duplicate entries.

[Paolo F Cantoni]

I've only looked as far as seeing that Instance_ID is not used by the API. It reads like it Instance_ID didn't exist when it was written.

I don't know about rationale, but at least this way it doesn't need to try to avoid duplicate entries.

• This is NOT an AddNew, but an Update
• There will be NO duplicate, the tuple DiagramID, ConnectorID will still be unique
• The whole Update fails, not just the ConnectorID
• The "new" ConnectorID is not present on the diagram before the update, so a New instance might be conceivable
• NO new instance is created

"It's broken, "

Paolo

[Eve]

I just tested it.

If I change the connector ID to another connector that is on the diagram, it updates that connector instead.
If I change it to a connector id to an id that isn't on the diagram the edit is discarded. (Which isn't what I thought it would do initially)

In both cases, it is protecting data integrity. (By not creating a duplicate entry and by not creating an entry that shouldn't exist)

If you want to copy the style to another connector, use AddNew and then copy the values. Regardless of having an Instance_ID, a diagram link is identified by the Diagram and Connector it applies to. You can't change that.

[Paolo F Cantoni]

I just tested it.

If I change the connector ID to another connector that is on the diagram, it updates that connector instead.
If I change it to a connector id to an id that isn't on the diagram the edit is discarded. (Which isn't what I thought it would do initially)

In both cases, it is protecting data integrity. (By not creating a duplicate entry and by not creating an entry that shouldn't exist)

If you want to copy the style to another connector, use AddNew and then copy the values. Regardless of having an Instance_ID, a diagram link is identified by the Diagram and Connector it applies to. You can't change that.

Then the documentation had better be fixed - especially since a Sparxian was "led astray"

We believe we have a genuine Use Case for using the Instance_ID in the same way that we can "replace" a diagram object, by changing the ObjectID without changing the Instance_ID.
 
We do NOT break data integrity (I am an Information/Data Architect, after all).

For us, it's now moot. We're using direct SQL to achieve our required outcome in this instance.  What we are actually (physically) doing in the repository is identical to our conceptual view.

Paolo

[Geert Bellekens]

Given the way the API works and automatically creates/deletes Diagramlinks depending on the relations between the elements of the DiagramObjects on the diagram,  I think both diagramID as connectorID should be set to readonly.

The current behavior is weird at best

Geert

[Eve]

I agree the behavior is weird. I'm just describing how it is.

Always hesitant to change existing functionality in the API.

[Geert Bellekens]

Always hesitant to change existing functionality in the API.

I can fully support that.
I have run into some changes to the API in the past, breaking my add-ins or script.

Geert

[Paolo F Cantoni]

Always hesitant to change existing functionality in the API.

I can fully support that.
I have run into some changes to the API in the past, breaking my add-ins or script.

Geert

I can't see ANY rationale for explicitly using the current behaviour in ANY existing user code.  So "fixing it" to subsume the current behaviour on disk for existing tuples, but including the new (expected) behaviour when there is no existing tuple for the diagram, to me, is just an API extension which CANNOT break any existing user code.  Now it may cause some issues on the Sparx side of the API, but my argument would be that that would be caused by existing defects in the existing API.

Everybody (even me) agrees that the current behaviour is weird.  I'm prepared to stand by my assertion that "it's broke, ".

Paolo