ExternalID is not related to ECO_TYPE
I just thought I'd blog about this because it seems to be causing some confusion.
ECO_TYPE
Use:
In integer used in the database to identify the type of object a table row represents.
Obtained from:
The ECO_TYPE table using the name of the class.
Life span:
Permanent. The name of the class in ECO_TYPE changes when you rename your class, but the integer value never changes.
ExternalId
Use:
A way of identifying a class instance across EcoSpace instances. Kind of like a string version of a pointer to an object.
Obtained from:
Index of the class in TypeSystem.AllClasses + "!" + the ECO_ID of the instance.
Life span:
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
1 ClassA
2 ClassC
03: You create an instance of ClassA and ClassB then look in the ClassA table in the DB, you will see something like this
ECO_ID ECO_TYPE
1 1
2 2
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
1 ClassA
2 ClassC
3 ClassB
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!
Pete
ECO_TYPE
Use:
In integer used in the database to identify the type of object a table row represents.
Obtained from:
The ECO_TYPE table using the name of the class.
Life span:
Permanent. The name of the class in ECO_TYPE changes when you rename your class, but the integer value never changes.
ExternalId
Use:
A way of identifying a class instance across EcoSpace instances. Kind of like a string version of a pointer to an object.
Obtained from:
Index of the class in TypeSystem.AllClasses + "!" + the ECO_ID of the instance.
Life span:
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
1 ClassA
2 ClassC
03: You create an instance of ClassA and ClassB then look in the ClassA table in the DB, you will see something like this
ECO_ID ECO_TYPE
1 1
2 2
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
1 ClassA
2 ClassC
3 ClassB
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!
Pete
Comments
as addition to this clear explaination: if instead of evolve DB a new one is created, then ECO_TYPE can change even for existing classes. It's not so obvious and pleasent because sometimes after model changes it is easier to create new DB and import data instead of evolving existing DB. But then pay attention to possibly changed ECO_Types!
Efim