I just thought I’d blog about this because it seems to be causing some confusion.
In integer used in the database to identify the type of object a table row represents.
The ECO_TYPE table using the name of the class.
Permanent. The name of the class in ECO_TYPE changes when you rename your class, but the integer value never changes.
A way of identifying a class instance across EcoSpace instances. Kind of like a string version of a pointer to an object.
Index of the class in TypeSystem.AllClasses + “!” + the ECO_ID of the instance.
Although the ECO_ID never changes the class index might when you add or remove classes within the model.
I just want to point out that ExternalID and ECO_TYPE are unrelated. When you change your model it does not mean that the ECO_TYPE in your DB must change. Here is an example
01: You create a model with 2 classes in it. The first class is the root, the next is a subclass
ClassA <---- ClassC 02: You generate the DB for the first time. This creates the ECO_TYPE table data with the following values ECO_TYPE CLASSNAME
03: You create an instance of ClassA and ClassB then look in the ClassA table in the DB, you will see something like this
04: Retrieving the ExternalID for each class will return 1!1 and 2!2. This looks like the ECO_TYPE but it isn’t!
05: You now change the model like so
ClassA <---- ClassB <---- ClassC 06: You evolve your DB. The result of this is the following A: A new entry in ECO_TYPE to enable ECO to see when a class is an instance of ClassB ECO_TYPE CLASSNAME
Note how the types are unchanged. There is no specific order to this list at all. It’s a first-come-first-served kind of arrangement.
B: Your ExternalID’s now change. The class index returned for each class is
ClassA = 1
ClassB = 2
ClassC = 3
Note that these have no relation at all to the ECO_TYPE. Just because they are both integers means nothing 🙂
I hope this clears it up. Remodeling does not mean all your DB type data needs to be updated!