Sparx Systems Forum
Enterprise Architect => Automation Interface, Add-Ins and Tools => Topic started by: Viking on June 12, 2020, 12:41:09 am
-
Hi,
I have a diagram with 2 Elements on it: a Class and an Instance of that class.
Is there a window in EA that shows the instances of a class? Instances are not listed in Property Window, Traceability Window, not under the class in the Project Browser, etc.
Is there a possibility in the EA Object Model to get the instances of a class? Or do I have to go through all DiagramObjects?
Are the instances of a class part of a collection of the class?
Furthermore I would like to change the classifier of the instance to another class via the EA OM. Can I just change the ClassifierID or is there something more to do?
V.
-
I found a helpful thread here:
https://www.sparxsystems.com/forums/smf/index.php?topic=26766.0
-
Hello,
Is there a window in EA that shows the instances of a class? Instances are not listed in Property Window, Traceability Window, not under the class in the Project Browser, etc.
Traceability can show the classifier / instance relationship, but I think it's switched off by default. Check the options in the Traceability window.
Is there a possibility in the EA Object Model to get the instances of a class? Or do I have to go through all DiagramObjects?
Are the instances of a class part of a collection of the class?
Element.ClassifierID in the instance matches the classifier's .ElementID, but there's no collection in Element that holds its instances.
The simple solution is to call Repository.GetElementSet() with an SQL query along the lines of
select Object_ID from t_object where Classifier = <classifier's ElementID>
Furthermore I would like to change the classifier of the instance to another class via the EA OM. Can I just change the ClassifierID or is there something more to do?
No, that's it. Not forgetting to call Element.Update() when you're done of course. :)
/Uffe
-
Hello,
Is there a window in EA that shows the instances of a class? Instances are not listed in Property Window, Traceability Window, not under the class in the Project Browser, etc.
Traceability can show the classifier / instance relationship, but I think it's switched off by default. Check the options in the Traceability window.
Is there a possibility in the EA Object Model to get the instances of a class? Or do I have to go through all DiagramObjects?
Are the instances of a class part of a collection of the class?
Element.ClassifierID in the instance matches the classifier's .ElementID, but there's no collection in Element that holds its instances.
The simple solution is to call Repository.GetElementSet() with an SQL query along the lines of
select Object_ID from t_object where Classifier = <classifier's ElementID>
Furthermore I would like to change the classifier of the instance to another class via the EA OM. Can I just change the ClassifierID or is there something more to do?
No, that's it. Not forgetting to call Element.Update() when you're done of course. :)
/Uffe
Thank you @Uffe for the select statement. I just need to copy and paste it :)
Yes, Traceability Windows works now as expected.
But I do not understand why there is no collection.
-
Hello,
Are the instances of a class part of a collection of the class?
Element.ClassifierID in the instance matches the classifier's .ElementID, but there's no collection in Element that holds its instances.
But I do not understand why there is no collection.
If this was an actual design decision, rather than a simple omission, I suspect it's for performance reasons.
Pre-loading collections of elements from the database which might in many cases not be needed slows the API down. (If indeed collection contents are pre-loaded and not loaded on demand.)
/U
-
Hello,
Are the instances of a class part of a collection of the class?
Element.ClassifierID in the instance matches the classifier's .ElementID, but there's no collection in Element that holds its instances.
But I do not understand why there is no collection.
If this was an actual design decision, rather than a simple omission, I suspect it's for performance reasons.
Pre-loading collections of elements from the database which might in many cases not be needed slows the API down. (If indeed collection contents are pre-loaded and not loaded on demand.)
/U
From my experience most collections are not preloaded.
Some don't even load completely when used. They load the objects when iterating. (you can see queries to the database when iterating a collection)
Especially this last one is a gotcha. We are using to think about collections as things that exist in memory, and that are cheap to iterate.
But some EA.Collections are really slow to iterate, as they have to load the objects details when doing a next.
So I learned myself to avoid EA.Collections as much as possible. The main thing is to get the ID's of what I need with an SQLQuery() and then get the objects using Repository.GetXXXByID
Doesn't work for everything, but it does speed up a lot of things.
Another thing is to never iterate an EA.Collection more than once.
If I have no choice but to iterate an EA.Collection (say I need the tagged values of a connector or something like that), and I'm going to need to iterate over it more then once, then I first put them in a regular collection such as a List<> (or ArrayList in vbscript)
Once that is done you can iterate the other collection as much as you want, without a performance penalty.
Geert
-
Once that is done you can iterate the other collection as much as you want, without a performance penalty.
Geert
Except you don't get noticed on updates under the hood done by other people. Usually not really an issue, but...
q.
-
Once that is done you can iterate the other collection as much as you want, without a performance penalty.
Geert
Except you don't get noticed on updates under the hood done by other people. Usually not really an issue, but...
q.
Exactly, but that is what you would expect from a collection in memory right?
The problem with EA.Collections is that they are not fish nor flesh (is that even a saying in English?) they are sortof in memory, but also sometimes go back to the database ???, and you never really know when they behave like fish, or when they behave like flesh.
Geert
-
Once that is done you can iterate the other collection as much as you want, without a performance penalty.
Except you don't get noticed on updates under the hood done by other people. Usually not really an issue, but...
Exactly, but that is what you would expect from a collection in memory right?
The problem with EA.Collections is that they are not fish nor flesh (is that even a saying in English?) they are sortof in memory, but also sometimes go back to the database ???, and you never really know when they behave like fish, or when they behave like flesh.
"Neither fish nor fowl" is what you're after there. :)
In general, it'd be very helpful if the API could provide more insight into / control over all the DB sync stuff. Last-retrieved timestamps, selective refresh, bulk write, all o' that.
So I learned myself to avoid EA.Collections as much as possible. The main thing is to get the ID's of what I need with an SQLQuery() and then get the objects using Repository.GetXXXByID
Doesn't work for everything, but it does speed up a lot of things.
I'll say. And for DocumentGenerator, fuggedaboudit. No more .DocumentElement for this sucker, it's custom templates and SQLQuery() from here on out. 8)
/U
-
Once that is done you can iterate the other collection as much as you want, without a performance penalty.
Geert
Except you don't get noticed on updates under the hood done by other people. Usually not really an issue, but...
q.
Exactly, but that is what you would expect from a collection in memory right?
The problem with EA.Collections is that they are not fish nor flesh (is that even a saying in English?) they are sort of in memory, but also sometimes go back to the database ???, and you never really know when they behave like fish, or when they behave like flesh.
Geert
The phrase (in English) is "neither fish nor fowl". I suspect this is only really known in the Queen's English[1]. I've never heard a 'Merican say it.
HTH,
Paolo
[1] Principally, the UK and Commonwealth countries.
-
The problem with EA.Collections is that they are not fish nor flesh (is that even a saying in English?)
It's from Shakespeare (Henry IV):
– Falstaff: Setting thy womanhood aside, thou art a beast to say otherwise.
– Hostess: Say, what beast, thou knave thou?
– Falstaff: What beast? why an Otter.
– Prince: An Otter sir John, why an Otter?
– Falstaff: Why? shees neither fish nor flesh, a man knowes not where to have her.
-
But I do not understand why there is no collection.
There aren't a lot of those potentially useful collections available in the API.
-
Fish nor fowl - There are variations on the theme. In English, some 20 years before the quote Neil gave you, it was said of a priest who was thought to have betrayed the Protestant church by promoting Catholic interpretations of the gospels that he was 'neither flesh nor fish'. And that was based on much older church advisories concerning the classification of things one could eat, an animal being either flesh, fish, or fowl. That is presumably where non-English versions of the phrase came from. The popular longer version is "Neither fish, nor flesh, nor good red herring" from Drydens's 'The Duke of Guise', some 60 years after Shakespeare wrote 'Henry V'.
Which is the 'fish' behaviour of Collections, and which the 'flesh'? (You've probably got 'fowl' behaviours already. And this whole aspect could be a 'Red Herring'.)
-
Fish nor fowl - There are variations on the theme. In English, some 20 years before the quote Neil gave you, it was said of a priest who was thought to have betrayed the Protestant church by promoting Catholic interpretations of the gospels that he was 'neither flesh nor fish'. And that was based on much older church advisories concerning the classification of things one could eat, an animal being either flesh, fish, or fowl. That is presumably where non-English versions of the phrase came from. The popular longer version is "Neither fish, nor flesh, nor good red herring" from Dryden's 'The Duke of Guise', some 60 years after Shakespeare wrote 'Henry V'.
Which is the 'fish' behaviour of Collections, and which the 'flesh'? (You've probably got 'fowl' behaviours already. And this whole aspect could be a 'Red Herring'.)
That was amongst your best! 8)
I too saw the reference to the red herring, but didn't want to "muddy the waters".
Paolo
-
Which is the 'fish' behaviour of Collections, and which the 'flesh'? (You've probably got 'fowl' behaviours already. And this whole aspect could be a 'Red Herring'.)
Not sure if you were asking a serious question, but I'm gonna answer it anyway
"Fish" could be: behave like a regular collection in memory, once loaded do not go back to the database
"Flesh" could be: behave like a proxy for the database, don't keep anything in memory at all.
Currently it's somewhere in between (Fowl?), with variations depending on the type of object in the collection. (Connectors collection could behave differently from Attributes collection)
Geert
-
Hello,
I want to assign the GUID of a classifier to an instance.
anInstance.ClassifierID = anElement.ElementGUID;I thought that both are strings and that it will work. It didn’t. The documentation says that ClassifierID is a Long an ElementGUID is a String. When I look into the database ea_guid and Classifier_guid look the same.
What’s wrong? V.
-
Hello,
I want to assign the GUID of a classifier to an instance.
anInstance.ClassifierID = anElement.ElementGUID;I thought that both are strings and that it will work. It didn’t. The documentation says that ClassifierID is a Long an ElementGUID is a String. When I look into the database ea_guid and Classifier_guid look the same.
Anyway. So I tried this:
anInstance.ClassifierID = Int16.Parse(anElement.ElementGUID); and all other conversions. But that is not correct either. What’s wrong? V.
ClassifierID is NOT a GUID
Paolo
-
It should be
anInstance.ClassifierID = anElement.ElementID
In EA most thing have both a regular ID (Long) as a guid (string)
The regular ID is (mostly) used to link things together, but they cannot be counted on to remain stable.
After say importing an xmi file, the ID's could be different. The ea_guid however will always stay the same.
In the database there is indeed also a field Classifier_guid, but you should not count on that. The real link is made using the Classifier column
Geert.
-
ClassifierID is NOT a GUID
Paolo
Yes, I am sorry, my question was nonsense :(