directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu (JIRA)" <directory-...@incubator.apache.org>
Subject [jira] Commented: (DIREVE-276) Search for super OC does not return subclasses if add op does not add complete objectClass lineage
Date Tue, 18 Oct 2005 20:01:45 GMT
    [ 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


Mime
View raw message