directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel L├ęcharny <elecha...@apache.org>
Subject Re: Subentries handling refactoring
Date Sun, 18 Jul 2010 08:09:50 GMT
  On 7/16/10 12:23 AM, Alex Karasulu wrote:
> Let me first give some heads up about what's going on.
>> This is what I will work on in the next few days if nobody objects or find
>> a better algorithm.
>>
>>
> I'm sorry but I have to veto this change. It's not acceptable to be taxing
> an LDAP server's read performance when this should be done during writes or
> during administrative changes.
I have to veto this veto :)

Ok, more srriously, let me explain what is the problem with the current 
approach.

let's say you have a DIT with 2 naming contexts :

dc=A
dc=B

Both of them are AP.

Now, we define a dc=sub-A,dc=A, which is also an AP with an 
accessControl subentry.

We now have the following structure (with the opAttr in square brackets, 
for clarity) (subentries are defined in ange brackets):
dc=A
<cn=A-subentry>
   dc=sub-A
<cn=sub-A-subentry>
     cn=entry1
       [accessControlSubentries: cn=A-subentry,dc=A]
       [accessControlSubentries: cn=sub-A-subentry,dc=sub-A,dc=A]
     cn=entry2
       [accessControlSubentries: cn=A-subentry,dc=A]
       [accessControlSubentries: cn=sub-A-subentry,dc=sub-A,dc=A]
dc=B
<cn=B-subentry>

Now, we want to move dc=sub-A,dc=A to dc=B. This will result to :
dc=A
<cn=A-subentry>
dc=B
<cn=B-subentry>
   dc=sub-A
<cn=sub-A-subentry>
     cn=entry1
       [accessControlSubentries: cn=A-subentry,dc=A]
       [accessControlSubentries: cn=sub-A-subentry,dc=sub-A,dc=A]
     cn=entry2
       [accessControlSubentries: cn=A-subentry,dc=A]
       [accessControlSubentries: cn=sub-A-subentry,dc=sub-A,dc=A]

Now, all the entries operational attributes are to be modified to gives 
the correct tree :
dc=A
<cn=A-subentry>
dc=B
<cn=B-subentry>
   dc=sub-A
<cn=sub-A-subentry>
     cn=entry1
       [accessControlSubentries: cn=B-subentry,dc=B]
       [accessControlSubentries: cn=sub-A-subentry,dc=sub-A,dc=B]
     cn=entry2
       [accessControlSubentries: cn=B-subentry,dc=B]
       [accessControlSubentries: cn=sub-A-subentry,dc=sub-A,dc=B]

So every move operation will impact potentially many entries, for an 
operation which is definitively *not* an administrative operation.

IMO, it's the same thing than when I decided to inject the full DN in 
entries, making the move operation costly - and we reverted back to a 
system where the move operation is O(1) instead of being O(N).
When we have subentries and operational attributes stored into entries 
referring those subentries, then the move operation is again one in O(N).

This is not acceptable, and of course, changing this comes with a price 
we have to pay for every user operation, but I don't see how we can 
accept to have an O(N) Move operation when we have subentries, but not 
when it comes to store the DN within the entries.

Thoughts ?

> There's a reason why I implemented it this way 5 years ago. I still think
> it's sound. It's a matter of when you choose to pay for the administrative
> change which BTW should not happen that often while reads happen all the
> time. I'd rather pay a lot for infrequent operations than a little bit for
> the most common operations.
>


-- 
Regards,
Cordialement,
Emmanuel L├ęcharny
www.iktek.com


Mime
View raw message