directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ersin Er <ersin...@gmail.com>
Subject Re: Subentries handling refactoring
Date Mon, 19 Jul 2010 07:44:07 GMT
As I had been involved in developing this part of the server, I have
discussed the issue with Emmanuel and I do not have more information to add
besides Alex's and Emmanuel's concerns.

X.500 is a cool spec that's hard or even impossible to implement in an
acceptable form.


On Sun, Jul 18, 2010 at 21:25, Alex Karasulu <akarasulu@apache.org> wrote:

> Hi Emmanuel,
>
> On Sun, Jul 18, 2010 at 11:09 AM, Emmanuel L├ęcharny <elecharny@apache.org>wrote:
>
>>  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 :)
>>
>>
> Heh :-).
>
>
>> 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.
>>
>>
> I figure you mean dc=sub-A is a subentry under dc=A which is the
> Administrative Point? Hmm but cn needs to be used for subentries.
>
>
>> 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
>>
>
> OK so dc=sub-A is an Inner Administrative Area nested withing dc=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]
>>
>>
> I thought dc=B is a peer of dc=A. So for cn=entry1 you should not have the
> reference any longer to subentry cn=A-subentry,dc=A. Likewise for entry2.
>
> OK below you update that ...
>
> 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.
>>
>>
> Not really this is still an administrative operation. You're moving around
> APs, inner or outer does not matter. The point is there are administrative
> changes and administrative costs associated with it. Moving non-AP entries
> is 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 a normal move operation. If you move an entry
> like cn=entry1,dc=sub-A,dc=A, then you have that O(1) cost. But you're
> moving an Inner Administrative Area, an Administrative Point. This
> potentially impacts N entries. It's not trivial and very complicated and I
> can see and live with the cost of such an operation.
>
>
>> 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 ?
>
>
> I think we have to make sure we understand what it is we're doing in this
> specific example. Moving an AP is an administrative function that can incur
> heavy costs. Your example is very complex because you chose an IAA instead
> of a regular entry to move.
>
>
>>
>>
>>  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.
>>>
>>>
>>
> --
> Alex Karasulu
> My Blog :: http://www.jroller.com/akarasulu/
> Apache Directory Server :: http://directory.apache.org
> Apache MINA :: http://mina.apache.org
> To set up a meeting with me: http://tungle.me/AlexKarasulu
>



-- 
Ersin ER

Mime
View raw message