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
