A reference to an object can be either hard or soft, and it can be either an ownership or pointer.

• Hard reference — The object depends on the referenced object for its viability.
• Soft reference — The object has some kind of relationship to the referenced object, but it is not necessary for its viability.

A reference to an object can also be categorized as either ownership or pointer:

• Ownership reference — the filing of objects which have the references. If one object owns another, then whenever the owner object is filed out, it takes the owned object to be filed together with it. Because an object can have only one owner, ownership references are used for non-redundant writing out of the database.
• Pointer reference — Any arbitrary references between objects. Pointer references are used for complete (redundant) writing out of the database.

These reference types define four relationships between objects: hard ownership, soft ownership, hard pointer, and soft pointer.

Hard ownership references

A hard ownership reference defines the relationship between objects when one object owns another object; the owned object cannot exist without the owner and the owner requires the owned object until the owner exists. The following examples are hard ownership references:

• A database object is a hard owner of its extension dictionary.
• The block table is a hard owner of model space and the block table record assigned as paper space, except any other block table records.

Soft ownership references

A soft ownership reference defines the relationship between objects when one object owns another object; the owned object cannot exist without the owner, but the owner does not need the owned object. The following examples are soft ownership references:

• A symbol table is a soft owner of its named records, except predefined records.
• A dictionary is a soft owner of its entries.

Hard pointer references

A hard pointer reference defines the relationship between objects when one object requires another object for viability; these object can have different owners. The following examples are hard pointer references:

• A text entity contains a hard pointer to a text style.
• A dimension entity contains a hard pointer to a dimension style.
• A multiline entity contains a hard pointer to a multiline style.

Soft pointer references

A soft pointer reference defines the relationship between objects when one object refers to another object, but these objects can exist independently. The following examples are soft pointer references:

• A group code of Xdata can contain a reference that is a soft pointer.
• A persistent reactor is a soft pointer.

Reference types and purging

A hard reference protects an object from a purge. For example, an entity contains a hard pointer to a layer. Therefore, a layer cannot be purged until it is pointed to by one or more entities. When a new database is written out from an existing database (for example, in the WBLOCK operation), all hard pointers are copied into the new database. A soft reference is simply a pointer to an object that does not protect the referenced object from a purge. When an object uses a soft pointer to another object, it should check whether the object still exists before opening it.

For example, the database must contain predefined symbol tables of layers, linetypes, blocks, text styles, etc., and the database can contain dictionaries of colors, multiline styles, materials, groups, etc. The layer table must contain the predefined layer record, named the zero layer, and can contain any user-defined layer records. The linetype table must contain three predefined linetype records, named the continuous, byLayer, byBlock, and can contain any user-defined linetype records. The block table must contain the model space block record and can contain any user-defined block records. A block record can contain any entities or can be empty. An entity requires a layer to which it belongs and a linetype by which it is drawn. An entity can contain XData that can refer to a color stored in the color dictionary. The following diagram demonstrates the reference types between these objects:

There are five classes for working with these four types of relationships between objects:

• OdDbHardOwnershipId — Implements a hard ownership reference to another object. This class is used when the owner requires the owned object, and the owned object cannot exist without the owner. This reference dictates that the owned object is written to .dwg and .dxf files whenever the owner object is written.
• OdDbSoftOwnershipId — Implements a soft ownership reference to another object. This class is used when the owner does not require the owned object, and the owned object cannot exist without the owner. This reference dictates that the owned object is written to .dwg and .dxf files whenever the owner object is written.
• OdDbHardPointerId — Implements a hard pointer reference to another object. This class is used when one object depends on the viability of another, but both are owned by other objects.
• OdDbSoftPointerId — Implements a soft pointer reference to another object. This class is used when neither object depends on the viability of the other object.
• OdDbTypeId — Implements a variable reference that can be set to a hard ownership, soft ownership, hard pointer, or soft pointer relationship. This class declares the setRefType() method which requires the reference type as an argument of the OdDb::ReferenceType type and sets the specified type of the relationship, and declares the getRefType() method which does not have arguments and returns the current reference type. The OdDb::ReferenceType enumerator defines four types of the relationship: kSoftPointerRef (=0), kHardPointerRef (=1), kSoftOwnershipRef (=2), kHardOwnershipRef (=3).

These five classes are derived from the OdDbObjectId class and inherit its functionality. They only redefine the comparison operators for own applying. These classes provide the specialization of the object ID for various types of relationships between objects within a database.

See Also

Identifying the Objects of Databases