Search for super OC does not return subclasses if add op does not add complete objectClass lineage

• Key: DIRSERVER-254
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Alex Karasulu
• Reporter: Alex Karasulu
• Affects Version/s: pre-1.0
• Fix Version/s: 1.0-RC1

Description

If I add an entry with objectClass inetOrgPerson to the directory but do not include in the objectClass attribute values for the super objectClasses like organizationalPerson and person then (objectClass=person) will not return the entry when it is in scope. To fix this is simple. Instead of adding tests for lineage on search operations which would be a nightmare we should pay the price on the add operation. Basically an interceptor can check that the lineage of objectClasses is present within the objectClass attribute. If not then it can be injected into the entry before the add operation takes place.

I don't know if this is correct behavior but it cannot hurt.

Comments

[Stefan Zoerner]

There are different options for a server to act, if a user adds an entry, where objectClasses are missing, like this one (comparable to your example)

dn: cn=Kate Bush,dc=apache,dc=org
objectClass: top
objectClass: inetOrgPerson
sn: Bush
cn: Kate Bush

I am not sure whether it is defined by the standard, how to react, but here are the options I found with example implementations (if I found any).

(1) Just add it as is. That is, the corresponding entry looks exactly like above (plus operational attributes)
Example for a server which acts like this:
OpenLDAP 2.1

(2) Fill the missing objectClasses during the add, resulting in an entry which looks like this:

dn: cn=Kate Bush,dc=apache,dc=org
objectClass: top
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
sn: Bush
cn: Kate Bush

Examples for a server which behaves like that:
Sun Java System Directory Server 5.2
IBM Tivoli Directory Server 6.0
Active Directory Application Mode (ADAM) (but it adds other classes as above)
Novell eDirectory 8.7.3

(3) Refuse to add the entry, e.g. with an error code for Schema Violation.
Examples for a server which behaves like that:
(none found yet)

I recommend application developers not to add such an entry, and then they do not face these different server reactions.

For our situation, I would recommend to implement (2) -- just as you suggested. (3) is better than (1) from my point of view, because people like to search by base classes, and it can't be up to us to check the whole hierarchy within a search operation (to expensive).

[Alex Karasulu]

I like how you have broken things down. As you say option (2) is best from a user experience standpoint I think. However the search implementation also benefits from this in terms of performance. Let me explain the advantages and disadvantages to each approach to clarify why (2) is best from an implementation standpoint.

Option #1
-------------

If (1) were the case the search algorithm would have to play it safe and presume every possible entry in the server can be incomplete in this fashion. For each candidate to evaluate, search would have to figure out the objectClass lineage for all objectClasses: this means, STRUCTURAL, ABSTRACT, and AUXILIARY. Then it must check to see if the assertion value matches one of these objectClasses. This is a lot of work to do while searching even if schema objects are cached in memory by the GlobalRegistries. It will slow down search which should be the fastest operation.

Option #3
-------------

Essentially the performance impact of this approach is the same as (2). The difference is in the schema checking semantics. This aspect for all directory protocols is undefined or I have yet to discover something definative on the matter. I'd rather fill in the blanks for the user which obviously implies all the subclasses for the more specific objectClass.

Option #2
-------------

This approach is optimal because objectClass attribute values for the entry are present in the entry when it is considered by search. Not only this but an index on objectClass works well. All values will be factored into the index for fast lookups without having to retrieve the entry from the master table. Further more values are normalized in the index.

There still is a cost to doing this in terms of space and time. The space is not as important as time. However the question is where do we pay this price? The price first of all is the fact that we will have to enumerate and inject all the objectClass values for the missing ancestors of a lineage. This we would have had to perform with option (1) during the search operation. However with option (2) the add operation pays the price once instead of having to pay this price every time a search is issued.

Conclusion
---------------

Without a doubt option (2) is superior to all options from both the implementation side and schema handling semantics.

[Alex Karasulu]

Implemented and tested ... see svn commit logs in JIRA.