IDs changed while cheking in\out

[Martin Terreni]

Here is a mailing chain between one of my developers  and Sparx support:
Developer:

I face a problem in trying to integrate version control handling in my add-in.
When I do check out to a package all the elements inside it get different IDs and the worst is that references of other elements( like element.ParentID, element.classifierID…) that  are in this package also get different IDs.
For example:
 I have an Instance element in package A and its classifier in package B. Then I do check out package B and
 when I try to retrieve element's classifier through element.ClassifierID I get an error because I actually trying to access an element with ID that is not existing.
 
1) Do you have some update – mapping IDs function after checkout to fix all references?
2) Or is there some workaround for this issue?
 
Steps to reproduce:
 
1. define package A and B under version control
2. place classifier element in package B and its instance in package A
3. checkout package B
4.try to find a the classifier through instance.ClassifierID

Support

Thank you for your email reporting the problems you are experiencing using EA's automation and version control functionality.
 
Your observations are correct - the object IDs do change after a checkout.  This is because when a package is checked out, it is first deleted from the database, then re-imported from the version controlled package file.  The object IDs that you are referring to are like indexes to the objects within the model database tables.  These IDs (and any pointers that you may have)  are invalidated when you perform a checkout.
 
The identifier that remains constant throughout the life of an object is the GUID.  There are functions within the automation interface such as GetElementByGUID( ).  You need to use these functions to find the items and initialise your references, AFTER you have checked out the relevant packages.

I hope this helps to clarify the issue.  Of course, if you have any further queries or problems, please don't hesitate to contact us again.

Developer

Thanks for your quick response.
 
I know about the option using GUID.
But it is available only as a property of an element itself.
If I want to access other elements  through : ParentID,ClassifierID,SupplierID...of specified element the GUID of these is not available.There are no such properties like: SupplierGUID or ClassifierGUID.
 
So if element's classifier is unfortunately in package that was checked out I can't find it using element.ClassifierID

Support

There is an Automation function "Refresh".
 
    Element myElement = repos.GetElementByGuid("{EFEDF398-68D0-46f4-9605-FE7547EDDFFD}");
    myElement.Refresh();
 
Looking at the code, this function uses the element's ObjectID to find to reload the object, so the call would probably fail if you called this function on an object that was part of a check-out.  However, for the instance element in PackageA that references a classifier element in PackageB, you should be able to call  myInstanceElem.Refresh( ) after you have checked out PackageB, to refresh to ClassiferID in the instance element.
 
If this does not work for you, or you have other scenarios where this can not be applied, then you will probably need to go through the process of reloading your items and retracing their references, after the checkout.
 
Presumably at some point you have called functions to find the references you need by using the element.parentID and element.classifierID attributes.
 
Maybe you need to relocate this code to a point after you have performed the checkout, or alternately, store the GUIDs of the elements that you have found and then renew your references after the check-out by calling something like the following, for the items of interest;
 
    Package myPackage = repos.GetPackageByGuid("{xxxx-nnn-xx-xx-nnxxnx}");
    Element myElement = repos.GetElementByGuid("{xxxx-nnn-xx-xx-nnxxnx}");
    Diagram myDiagram = (Diagram)repos.GetDiagramByGuid("{xxxx-nnn-xx-xx-nnxxnx}");
 
 
The Automation Interface is not my area of expertise, but as far as I know, it does not include a function to "update mapping IDs".
 
 
I hope this information is of some help.

A couple of things

• Why is it not mentioned in help?
• If this is the status why are supplying API operations working with ID? replace them al to use GUID

I think I'm making sence here.

[«Midnight»]

First, if the documentation is off submit a report to Sparx. Roy et al have been doing legion duty on updating the documentation, but they cannot fix what they don't know about. Since there were already about 1200 pages when Roy first took up this challenge there is a lot of catch-up that has to be done.

Second, the ID stuff appears to date back to the olden days of EA. Thus some of it is legacy. FWIW some DBMS products handle (or did handle) integer IDs more gracefully than a GUID field. This is particularly true if you want to use the 'raw' GUID rather than translate it to a string. Perhaps this affected how these were used.

You will note for example that the GUID field is (or was, last time I looked) not even treated as a (database-enforced) index in some cases.

David

[Martin Terreni]

First, if the documentation is off submit a report to Sparx.

As you see, we communicated to Sparx

Second, the ID stuff appears to date back to the olden days of EA. Thus some of it is legacy. FWIW some DBMS products handle (or did handle) integer IDs more gracefully than a GUID field. This is particularly true if you want to use the 'raw' GUID rather than translate it to a string. Perhaps this affected how these were used.

It might all be true (and it probably is) yet if they expose and API which works with IDs it should work properly, and if they suggest to work with GUID then the API should work with GUID also.
I'm a customer, not a friend next door, and not all the time the reason for these problems are relevant to me, in this case  - they are not.
I expect to get a product which works in a predictable way so I can properly predict the service I give to MY customers, who also want a predictable work.

[Paolo F Cantoni]

I expect to get a product which works in a predictable way so I can properly predict the service I give to MY customers, who also want a predictable work.

You mean there's two of us?

Go for it Martin!

The trouble is, EA IS predictable!  It will be self-inconsistent.  You want something that works consistently with itself and its documentation and other applications in the same environment.

Paolo

[«Midnight»]

Of course you meant "three" Paolo, assuming you're including yourself...

 

[Martin Terreni]

I guess this is predictable