Sparx Systems Forum
Enterprise Architect => Automation Interface, Add-Ins and Tools => Topic started by: Paolo F Cantoni on March 05, 2019, 12:40:13 pm
-
The Documentation says:
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
-
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.
-
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
-
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.
-
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
-
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.
-
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
-
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.
-
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
-
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.
-
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
-
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 :-X
Geert
-
I agree the behavior is weird. I'm just describing how it is.
Always hesitant to change existing functionality in the API.
-
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
-
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
-
I can't see ANY rationale for explicitly using the current behaviour in ANY existing user code.
Copying the style properties from one diagramlink to another.
-
I can't see ANY rationale for explicitly using the current behaviour in ANY existing user code.
Copying the style properties from one diagramlink to another.
No, I meant with respect to the two IDs. Obviously, copying properties doesn't require changing the ID, merely synchronising the properties.
Our Use Case is similar. In our case, it's moving the properties from one connector to another (new) connector. We want to discard the previous connector from the diagram.
Paolo
-
I was providing an example of how an existing client could be using the existing behavior. Currently anyone can copy the complete style from one diagram link to another by changing the connector id and/or diagram id and calling update.
-
I was providing an example of how an existing client could be using the existing behaviour. Currently, anyone can copy the complete style from one diagram link to another by changing the connector id and/or diagram id and calling update.
I was thinking about this and this isn't an example of a Use Case, its an example of an Abuse Case.
It violates so many data integrity concepts... It smacks to me of the "Streaker's Defence" - "It seemed like a good idea at the time, your honour..."
The table is defined with Instance_ID as the primary key and the tuple DiagramID, ConnectorID is NOT defined as a unique key. So there is no concept of the DiagramID, ConnectorID defining a link. (In fact, we've noticed occasional duplicate link errors when running the integrity checker - so they might be caused by the faulty API also).
The API needs to respect these rules. Otherwise, we as users can't expect anything to work. As it is we've discovered we issued a specific instruction, only to find the API decided to do something else...
"It's a bug, "
Paolo
-
My experience with Sparx is just that there's no point in discussing things like that with them. "James," (seems a fit for the partner of since I don't know her) "the discussion is futile".
q.
P.S. Oh what a coincidence that this post was my 10^4th.