An External ID consists of two parts,
ClassID isn’t really required for ECO controlled DB structures because there is always a root table containing the ObjectID + ClassID, but when you use ECO to map to an existing DB structure there needs to be a way to know that object 1234 needs to be fetched from the PERSON table.
So, now that we know why the ExternalID consists of two parts on to why I don’t use it (much). If I am writing a website with ECO and I use the ExternalID for my URL like so
The number 23 is determined by looking for the class’s index in the list of all classes in the model. This is the problem! If you change your model by adding a new class then your index may change from 23 to 24. Not a big problem for your application, but persistent links to that URL from other sites such as Google will no longer work.
An ExternalID is just like an object’s pointer address. When you restart your application that address is no longer valid. ExternalID lives longer than an application restart, but doesn’t always live past an application remodeling as explained above.
My tips are as follows:
- For passing object instances around in code, just past the object instance itself.
- For passing a reference to an object to another EcoSpace instance in the same application use ExternalID.
- For storing away a reference for an unknown period of time (config file settings, URLs) add a unique attribute to your class such as an AutoInc and retrieve it using that value in an OCL evaluation.
URLs are really the only example I can think of where an ExternalID is persisted externally and expected to live longer than the life of the current model. In this case I think the following URL is much more pleasing to the eye anyway