Each object has a key. A key is a combination of one or more object’s attributes, which uniquely identifies a particular object. The key structure is defined in the object type – and the uniqueness applies to all objects of the type where the key is defined, not to all objects across the database (as is the case for the uniqueness of the id).

Example 1

For both the object types ‘user’ and ‘group’, the key is the name attribute. This means that there can be only one user object with name ‘admin’, but this does not prevent the existence of a (unique) group object with the same name ‘admin’. The ‘admin’ user and the ‘admin’ group will have two different numeric ids.

Example 2

If the key for the object type ‘namedObject’ is the name attribute, there can be only one object with type ‘namedObject’ or any descendent type that does not define its own key with a given name.

For example,  the object types ‘namedA’ and ‘namedB’ derive from namedObject and do not have a separate key definition, if there is a namedA object called ‘XYZ’ there cannot be another namedA or a namedB or a namedObject object called ‘XYZ’.

The order of the attributes composing the key is important: a key made of the ‘name’ and ‘folder’ attributes is different than a key made of the ‘folder’ and ‘name’ attributes.

String attributes used as part of keys are case-insensitive. In the example above, the existence of a user named ‘admin’ prevents the insertion of users called ‘Admin’, ‘ADMIN’ and all other case combination.

Note that it is not possible to use as part of the object key the string attributes that have a large maximum length and so are stored in the database as unlimited length fields (‘ntext’ in SQL Server or ‘nclob’ in Oracle).

See also

Defining the object type key