Schema checking

When the server is initialized, the schema files are read and checked for consistency and correctness. If the checks fail, the server fails to initialize and issues an error message. During any dynamic schema change, the resulting schema is also checked for consistency and correctness. If the checks fail, an error is returned and the change fails. Some checks are part of the grammar (for example, an attribute type can have at most one supertype, or an object class can have any number of superclasses).

The following items are checked for attribute types:

• Two different attribute types cannot have the same name or OID.
• The inheritance hierarchy of attribute types does not have cycles.
• The supertype of an attribute type must also be defined, although its definition might be displayed later, or in a separate file.
• If an attribute type is a subtype of another, they both have the same USAGE.
• All attribute types have a syntax either directly defined or inherited.
• Only operational attributes can be marked as NO-USER-MODIFICATION.

The following items are checked for object classes:

• Two different object classes cannot have the same name or OID.
• The inheritance hierarchy of object classes does not have cycles.
• The superclasses of an object class must also be defined, although its definition might appear later or in a separate file.
• The "MUST" and "MAY" attribute types of an object class must also be defined, although its definition might appear later or in a separate file.
• Every structural object class is a direct or indirect subclass of top.
• If an abstract object class has superclasses, the superclasses must also be abstract.

Checking an entry against the schema

When an entry is added or modified through an LDAP operation, the entry is checked against the schema. By default, all checks listed in this section are performed. However you can selectively disable some of the schema checking by changing the schema checking level. This is done through iSeries Navigator by changing the value of the Schema checking field on the Database/Suffixes page of the Directory Server properties. See Directory Server configuration schema for information about schema configuration attributes.

To comply with the schema an entry is checked for the following conditions:

With respect to object classes:

• Must have at least one value of attribute type "objectClass".
• Can have any number of auxiliary object classes including zero. This is not a check, but a clarification. There are no options to disable this.
• Can have any number of abstract object classes, but only as a result of class inheritance. This means that for every abstract object class that the entry has, it also has a structural or auxiliary object class that inherits directly or indirectly from that abstract object class.
• Must have at least one structural object class.
• Must have exactly one immediate or base structural object class. This means that of all the structural object classes provided with the entry, they all must be superclasses of exactly one of them. The most derived object class is called the "immediate" or "base structural" object class of the entry, or simply the "structural" object class of the entry.
• Cannot change its immediate structural object class (on ldap_modify).
• For each object class provided with the entry, the set of all of its direct and indirect superclasses is calculated; if any of those superclasses is not provided with the entry, then it is automatically added.
• If the schema checking level is set to Version 3 (strict) all structural superclasses must be provided. For example, to create an entry with objectclass inetorgperson, the following objectclasses must be specified: person, organizationalperson, and inetorgperson.

The validity of the attribute types for an entry is determined as follows:

• The set of MUST attribute types for the entry is calculated as the union of the sets of MUST attribute types of all of its object classes, including the implied inherited object classes. If the set of MUST attribute types for the entry is not a subset of the set of attribute types contained by the entry, the entry is rejected.
• The set of MAY attribute types for the entry is calculated as the union of the sets of MAY attribute types of all of its object classes, including the implied inherited object classes. If the set of attribute types contained by the entry is not a subset of the union of the sets of MUST and MAY attribute types for the entry, the entry is rejected.
• If any of the attribute types defined for the entry are marked as NO-USER-MODIFICATION, the entry is rejected.

The validity of the attribute type values for an entry is determined as follows:

• For every attribute type contained by the entry, if the attribute type is single-valued and the entry has more than one value, the entry is rejected.
• For every attribute value of every attribute type contained by the entry, if its syntax does not comply with the syntax checking routine for the syntax of that attribute, the entry is rejected.
• For every attribute value of every attribute type contained by the entry, if its length is greater than the maximum length assigned to that attribute type, the entry is rejected.

The validity of the DN is checked as follows:

• The syntax is checked for compliance with the BNF for DistinguishedNames. If it does not comply, the entry is rejected.
• It is verified that the RDN is made up with only attribute types that are valid for that entry.
• It is verified that the values of attribute types used in the RDN appear in the entry.