Sparx Systems Forum
Enterprise Architect => Automation Interface, Add-Ins and Tools => Topic started by: bilon on August 09, 2018, 07:33:02 pm
-
We plan to relocate some tags. It looks, according to my tests, that it's enough to sync stereotypes and everything will be ok. Is there any other impact I should know bout?
-
I doubt if the tagged values for which you have set some value (other than default) will be removed, it will only be moved from the MDG profile to normal tags.
Whilst Synchprofile will add, for removing any applied tags, a script must be used.
-
Concur with Nizam a script to remove existing tagged values.
There is a script in the topic url below to add tagged values which could be modified to remove tagged values.
https://www.sparxsystems.com/forums/smf/index.php/topic,40259.0.html (https://www.sparxsystems.com/forums/smf/index.php/topic,40259.0.html)
Pre-requist: You'll need to have skills in JavaScript.
-
I don't understand, what I need a script for. Here is my scenario:
I have two stereotypes ST_A, ST_B, which are assigned to all tables. ST_A owns two tags, TV1 and TV2. Now I edit profile and move TV2 from ST_A to ST_B. When I open the model, I see TV2 as a standalone tag (not under a stereotype but under the table class). After synchronizing the ST_B stereotype I see the TV2 under it. It retains it's original value, even non-default.
Do you see something that I missed and could be a issue?
-
"relocate tags" is a very rough description and leaves room for lots of interpretation. What is the reason for doing it? What exactly shall be the outcome?
q.
-
I don't understand, what I need a script for. Here is my scenario:
I have two stereotypes ST_A, ST_B, which are assigned to all tables. ST_A owns two tags, TV1 and TV2. Now I edit profile and move TV2 from ST_A to ST_B. When I open the model, I see TV2 as a standalone tag (not under a stereotype but under the table class). After synchronizing the ST_B stereotype I see the TV2 under it. It retains it's original value, even non-default.
Do you see something that I missed and could be a issue?
I think that is fine like that.
If you were to move tagged values from one element (table) to another (e.g. package), then you would need a script.
Geert
-
No no, it is not to move the tag from one element to another but from one stereotype to another stereotype. And both stereotypes are present on all the tables in the model. So the tag will stay on all the tables too.
-
Just rename the stereotype and you should be done.
But to rename the stereotype you have to do that for all stereotyped elements. Without a script you will have a hard time.
You "could" go directly to the database. But that would probably have the need for doing awkward string manipulations in t_xref.
q.
-
No no, it is not to move the tag from one element to another but from one stereotype to another stereotype. And both stereotypes are present on all the tables in the model. So the tag will stay on all the tables too.
Each tagged value that comes from a profile is uniquely identified, including the stereotype that it comes from. If you move the tagged value definition to the supertype of its current stereotype that will still change. The result is that any existing tags will no longer match the definition, they will then appear to be not from any profile because they don't match any available tag definition.
-
Have you read my yesterday's post, where I described my scenario? For me, the result is ok - the moved tag is displayed under the new stereotype (ST_B) instead of the original stereotype (ST_A). And this was the purpose. So where is the problem?
-
I was talking about the impact such a change would have on the existing tagged values for elements with those stereotypes already applied. You can probably correct that by running a synchronize stereotype though.