3.1.1.2.5 Constraints

The table definitions specify constraints on properties other than those that are implied by their type, size, and flags. All COMA servers MUST ensure that their catalog conforms to these constraints.

For the purposes of this protocol, two types of constraints can be distinguished: referential and nonreferential. Referential constraints restrict the legal values of a property in an entry based on properties of other entries, including possibly entries in other tables (for example, constraints that reflect containment relationships). Nonreferential constraints restrict the legal values of a property independently of the properties of any other entries (for example, a range of legal values for a configuration property).

An important class of referential constraints is primary key constraints. Each table definition specifies a set of properties in the table as its primary key. Entries are constrained so that an entry is uniquely identified by its values for the primary key properties. In other words, there exists at most one entry in the table with any given value assignment to all the values in the primary key.

A COMA server MAY enforce implementation-specific, nonreferential constraints, as long as these constraints are more restrictive than those that are specified in the table definitions. For example, a server MAY constrain an unused property to a default value. The ICatalogTableWrite::WriteTable (see section 3.1.4.9.1) method specifies a mechanism by which a server can return TableDetailedError records (see section 2.2.1.16) to indicate to the client the reason for a failed write. If a server enforces implementation-specific constraints more restrictive than those that are specified in the table definitions, it SHOULD return TableDetailedError records for writes that fail due to these more restrictive constraints.

A COMA server MUST NOT enforce any referential constraints except those that are specified in the table definitions.