Hey guys,
I did a bit of a dive on this. Find something to hold on to, and make sure you've got some paracetamol to hand.
Object_Type = "Table" is definitely wrong.
Well... For a given value of "definitely", perhaps. But this. Is. EA!!! (cue Gerard Butler)
It is, in fact, the Class/«table» elements that are wrong. The correct representation is Table/«table».
You can test this very easily (this is on 1557).
If you create a table in a Data Modeling diagram, the element gets Object_Type "Table" and stereotype «table».
If you import a schema from a DBMS, again you get Table/«table» (and View/«view»).
Whether this is something that's been changed recently I can't say. I did a quick check of the histories and there's nothing that indicates that it has, but it is possible.
Now, as I understand it the t_object.Object_Type is the same as EA.Element.Type, or am I missing something?
You are. The profile-defined metatype.
Element.Type is sort of the UML base type. The API documentation lists the valid contents, and you'll note Table isn't in there but Class is.
t_object.Object_Type, on the other hand, holds the metatype if there is one and the base type only if there isn't. In this case, the metatype is Table, as you can see in the corresponding
Element.Metatype attribute.
Now I say that
Element.Type is a "sort of" base type, and unfortunately that's because this is pretty sloppily defined. Again, if you refer to the API documentation you'll see that it's not just UML base types in there (Activity, Class, Component...) but also some of EA's core extensions such as GUIElement, Issue and Requirement.
EA's representation of a database table, however, is not a separate element type in the core extensions, but a profile-defined metatype.
There are essentially four categories of element type in EA:
- Types defined in the UML standard;
- Types defined as their own element types in EA (Requirement);
- Types defined with their own metatypes in Sparx-supplied profiles (Table), which get special treatment in the GUI and various functions (more below);
- Types defined with their own metatypes in third-party profiles, which don't get special treatment.
I don't think that EA actually differentiates between categories 1 and 2. They're just what we might call built-in types, and what's listed under the Type attribute in the
Element API documentation is the sum total.
Telling categories 1/2 and 3 apart can be very difficult, and again, I don't know of any documentation that clarifies it other than that list.
The in-project representation gets a little tricky because there is no "Metatype" column in
t_object. There's
.Object_Type and
.Stereotype, and that's it. (I'm choosing to ignore
.NType, as far as I've been able to ascertain it doesn't enter into this.)
t_object.Object_Type will hold the (cat 3/4) metatype if one is defined, and only if the element has no profile-defined metatype will
.Object_Type hold the (cat 1/2) base element type. (Whether a stereotype has a profile-defined metatype is a choice made by the profile designer.)
In both cases,
t_object.Stereotype will hold the stereotype's simple name. The fully-qualified stereotype is stored in
t_xref.
When going through the API, EA does it differently because there are separate
Element attributes for
.Type,
.Metatype,
.Stereotype and
.FQStereotype.
So a correctly created database table element should appear as follows:
- Database
- t_object.Object_Type = 'Table'
- t_object.Stereotype = 'table'
- t_xref.Description = '@STEREO;Name=table;FQName=EAUML::table;@ENDSTEREO;'
- API
- Element.Type = 'Class'
- Element.Metatype = 'Table'
- Element.Stereotype = 'table'
- Element.FQStereotype = 'EAUML::table'
As I was writing this, Qwerty responded.
EA's query results are mingled and not a direct representation of the table contents. Esp. object type is changed towards the metatype defined for the element.
Normally I defer to Q on the details of the database, but are you actually sure about this? I would have assumed that EA
stores the metatype as I describe above, not that it fudges the query results.
In either case, the CSV import/export also differentiates between the base element type and the metatype, and I suspect this is what's causing the problem. In a CSV specification, the metatype is referred to as "Profile Metatype" and it must be included for a CSV import to work when dealing with metatyped elements.
A proper export of a package containing a correctly defined database table should look something like
GUID;Type;Profile Metatype;Stereotype;Fully Qualified Stereotype;Name
{E91B88AA-AB9F-40ae-B970-34D6CA0E9C8B};Class;EAUML::Table;table;EAUML::table;Tabellen Ellen(I've included the simple stereotype name for completeness. It should be omitted in production.)
As you can see, the CSV import/export also includes the profile name in the metatype name. The API does not, and it isn't stored that way in
t_object.
So.
So when I do an csv export these two table both report CLass for Element.Type.?
What is happening here?
You are exporting only the base type, not the metatype.
This should be obvious when you import the data into another project, but unfortunately EA obscures this error by being "helpful".
If your CSV data contains Type and Stereotype, but not Profile Metatype, then on import EA won't know that you want to create Table/«table» elements. It will find only Class/«table» elements in there, and will create exactly that.
(I am assuming that you are working with simple stereotypes too. I believe fully-qualified stereotypes might also have worked, but I haven't tested this.)
But here's where it gets murky. In a fresh project created from scratch (that is, from the default base project) EA includes a bunch of in-project stereotypes which do not belong to any profiles at all. Crucially,
there is a non-profile «table» stereotype in amongst them.
So it is quite possible to create a Class in a regular class diagram, then set its stereotype to the profile-less «table».
You can also set the stereotype of a Class to «table» from the EAUML profile. Of course you can -- the EAUML::table stereotype applies to Class, after all.
If you set a class stereotype to EAUML::table, EA changes its
t_object.Object_Type from 'Class' to 'Table'.
If you set a class stereotype to the profile-less «table», EA sets its
t_object.Object_Type to 'Class'. So EA does a lot of footwork when you change stereotypes, and importantly, you can change a properly-defined Table/«table» element to an ill-defined Class/«table» this way.
This "helpfulness" isn't limited to the ill-defined profile-less «table» stereotype.
EA also treats a Class/«table» as if it were a proper Table/«table»: it shows it as a database table in diagrams, and when prompted to open the properties dialog it opens the table-specific dialog instead of the generic class one, allowing you to edit columns instead of attributes, etc. But the project browser does show the difference between a Table/«table» and a Class/«table» in that only a Table/«table» has the table-style icon.
Finally, you mention that
I've checked types, Stereotypes, FQStereotypes, Profile Types, PackageID, ...
This omits both metatypes and GUIDs. I've talked (at length) about metatypes but if you've somehow managed to get duplicate GUIDs in t_object your project is seriously broken, although I would expect the integrity check to pick up on that.
Going forward, your CSV specifications should always include metatypes and only ever use fully-qualified stereotypes, and all new projects should immediately be cleared of all "helpful" stereotypes and tagged value types. It is worth setting up your own base project for this.
I hope this helps. I really do.
/Uffe
