eDirectory classes are either effective or non-effective. Non-effective classes can be either auxiliary classes or super classes, but they cannot be used to create entries in the database. Effective classes are the base classes that are used to create entries in the database. They can also be super classes. From super classes, classes inherit attributes and may inherit other structural features such as naming and containment .
Since a super class is a class definition, it has its own relational database table, and you can generate reports from these super class tables. However, to generate reports without surprises, you need to be aware of how eDirectory and the ODBC driver use super classes.
eDirectory has a hierarchical schema, and more than one class can inherit from the same super class. For example, Top is a super class of all effective classes, and ndsLoginProperties is a super class of User, Person, Organizational Person, Organization, and Organizational Unit.
The ODBC driver determines the base set of entries for a table by performing an eDirectory query for all entries whose Object Class attribute contains the class associated with the table. The Object Class attribute for each entry is multi-valued and contains the names of the entry’s base class, its super classes, and auxiliary classes. For example, the Object Class attribute for User entry would always include the following classes: Top, ndsLoginProperties, Person, Organizational Person, and User.
Thus, if you run a report using the ndsLoginProperties table, the table could contain entries from the following base classes: User, Person, Organizational Person, Organization, and Organizational Unit. In addition, if your schema has been extended to include classes that define ndsLoginProperties as a super class such as residentialPerson and inetOrgPerson, then the table could contain entries from these classes.
When using a table from a super class, you should use the special column, NDS_Name, for the entry’s name rather than an attribute such as CN. Not all classes use CN as their naming attribute, and some super classes do not define a naming attribute. The NDS_Name column retrieves the entry’s name regardless of the naming attribute.
For an example query using a super class table, see Section 4.14, Super Class Query.
For more information about super classes, see the Novell eDirectory Schema Reference.
Auxiliary classes also require some special handling. Since they are a class definition, they have their own relational database table, and you can generate reports from them. To generate a report, you should be aware of the following features of auxiliary classes.
Auxiliary classes are assigned to individual entries in the directory rather than to a base class. Therefore, not all entries of a base class will have the auxiliary class value in their Object Class attributes and entries of other base classes may have the auxiliary class value in their Object Class attributes. An auxiliary class can be assigned to any entry in the directory. For example, Partition is an auxiliary class in NDS 8.xx and is assigned to any container entry such as a Country, Organization, or Orgranizational Unit entry that becomes the partition’s root.
The ODBC driver determines the base set of entries for an auxiliary class table by performing an eDirectory query for all entries whose Object Class attribute contains the auxiliary class associated with the table. The Object Class attribute for each entry is multi-valued and contains the names of the any auxiliary classes assigned to the entry.
You should use the special column, NDS_Name, to include the entry’s name in the report because most auxiliary classes do not include naming attributes and because not all base classes use the same naming attribute. (For more information about auxiliary classes, see the eDirectory Schema Reference.)
For an example query using an auxiliary class table, see Section 4.2, Auxiliary Class Queries.
An auxiliary class table contains only the attributes defined for the auxiliary class. At times you may want to create a query that returns columns for the auxiliary class attributes and base class attributes. To do this, you must perform a join between the base class and the auxiliary class. The join should be performed on the NDS_FullName field. For an example, see Section 4.6, Join Query.