# Object Identity

CDOIDs are technical identifiers for CDOObjects.

## Lifecycle of CDOIDs

Objects are always initially created at the client side by pulling them from an EFactory. CDOObjects are in state TRANSIENT at this time and do not have a CDOID.

As soon as the object is attached to a CDOTransaction (by making it contained by an existing resource or object, that is already persistent) the state is changed to NEW and a temporary CDOID is assigned to it. Temporary CDOIDs are internally integer values that are unique only in the scope of this CDOTransaction (more exact: in the scope of the next commit operation to happen). Temporary CDOIDs can be cast to CDOIDTemp and their isTemporary() method returns true.

When the CDOTransaction is committed the NEW objects are sent to the repository. Before they are persisted by the repository (more exact: by the store of the repository) the temporary CDOIDs are replaced by permanent ones which are unique in the scope of the whole repository. As part of this ID mapping all references to these objects are adjusted to the newly assigned, permanent CDOIDs. Permanent CDOIDs can be cast to CDOIDObject and their isTemporary() method returns false.

Finally the mappings from temporary to permanent CDOIDs is sent back to the client where the permanent CDOIDs are assigned to the NEW objects and all references to them are adjusted accordingly. The state of all objects in a CDOTransactionis CLEAN after a successful commit operation.

## Class loading of CDOIDs

It is the responsibility of the store in the repository to create and assign permanent CDOIDs to NEW objects. The store is allowed to utilize whatever implementation of the CDOID interface seems appropriate for a given back-end. This may include code that is not present on the client side. Such situations are automatically detected by the client when a new CDOSession is opened to the repository and one or more Java archives are downloaded and cached on the client side. These JARs may contain:

1. The implementation code of the CDOIDs for the particular back-end type.
2. A factory class to produce instances of these CDOIDs.
3. Optimized serialization/deserialization code
4. Optionally any code that is needed to make the above work.

If a store implementation deals with CDOID implementations unknown to the framework, then each CDOSession to this repository maintains a separate instance of a ClassLoader for the instances of these CDOIDs. As a consequence it may not be possible to even compare CDOID instances that stem from different CDOSessions!

If a store implementation uses one of the default CDOID implementations, like CDOIDLongImpl, all instances of them are created by the normal framework ClassLoader. In this case store implementors may choose the abstract LongIDStore class as a base class for their custom store implementation.

## Types of CDOIDs in References

There are four different types of CDOIDs depending on the type of the referenced object and the persistence infrastructure the referenced object is contained in:

1. CDOID.NULL is a special value that can be used as a reference target but not as the CDOID of CDOObjects.
2. Object IDs are the CDOIDs for references to normal objects (i.e. not meta objects, see below) that are managed by the same CDOView as the referencing object. They are also known as internal CDOIDs to separate them from external CDOIDs (see below).
3. Meta IDs are special CDOIDs used to reference instances of EModelElements stored in the meta section of the model repository. They are rarely used but they allow your business objects to refer to their own (or other) definitions.
4. External IDs are used to reference any objects that are not managed by the same CDOView as the referencing object. These can be CDOObjects in different CDOViews or CDOObjects that are not managed by any CDOView at this time or simply non-CDO objects.

All CDOID types except CDOID.NULL support the difference between temporary and permanent values.

- CDOID Factories
  Represents some real concept.
- CDOID Class Loaders
  Represents some real concept.

Parent topic: Objects