[ http://issues.apache.org/jira/browse/DIREVE-276?page=comments#action_12332400 ]
Alex Karasulu commented on DIREVE-276: -------------------------------------- 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. > Search for super OC does not return subclasses if add op does not add > complete objectClass lineage > -------------------------------------------------------------------------------------------------- > > Key: DIREVE-276 > URL: http://issues.apache.org/jira/browse/DIREVE-276 > Project: Directory Server > Type: Bug > Reporter: Alex Karasulu > Assignee: Alex Karasulu > Fix For: 0.9.4 > > 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. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
