[389-devel] Please review: Allow modrdn to move subtree and rename non-leaf node

[Noriko Hosoi]

Hi Andrey,

Thanks so much for reading through the design doc!  My responses are in 
line...

On 01/14/2010 07:45 AM, Andrey Ivanov wrote:
> Hi Noriko,
>
>    
>>   Allow modrdn to move subtree and rename non-leaf node
>>
>>     This patch includes
>> ...
>>      
> I've read your design and implementation guide. It is very detailed
> and discusses a lot of questions in a rather comprehensive way. A lot
> of uncertainties i had in the beginning of the document were resolved
> at the end (for example, the "ancestorid investigation").
>
>
> Here are some questions or remarks that i still do have after this reading:
> Citation:
> -------------------
> This function entryrdn_index_read finds out the entry_id of the given
> DN sdn. It starts from the suffix in the entryrdn index following the
> child links to the bottom. If it is successful, the entry_is of the
> target node is set to the address that the argument id points to.
> -------------------
>
> the previously used "entrydn" index and the corresponding function
> needed just one step(?) to find out the entry id from it's dn. Several
> steps are now needed with "entryrdn" index.
That's right.
> You talk about an
> expensive entry_id ->  dn conversion and you introduce the dn cache to
> take care of it. However you don't mention the expensive conversion dn
> ->  entry_id (that was the role of entrydn.db4). As far as i understand
> the standard entry cache should help this conversion? And maybe this
> type of conversion is much less frequent than  entry_id ->  dn?
>    
Yes and yes.  That's my observation.  If you have a dn (operations from 
clients always have it), the matched entry is retrieved from the 
database first, then put in the entry cache.  As long as the entry cache 
holds the entry, dn -> entry_id will not be needed.  On the other hand, 
entry_id -> dn is more engaged especially when you need to scan the 
primary db file id2entry.db4.  That occurs on the unindexed search.  
Unindexed search is generally slow, but without dn cache, it'd be even 
worse...
> It would be interesting to have an estimation of the performance loss
> (or gain?) due to this new entryrdn index for typical read/search
> operations - 3 to 5 levels of rdn in DIT... I think it can be done
> with ldclt in a similar way you've done it for ancestorid index.
>    
A very good idea.  I'm going to run the tests and push the results to 
the wiki.
> One can extend your investigation of ancestorid index further: while
> we use entryrdn index is there still a need to maintain parentid
> (numsubordinates, ancestorid)?  One of the points is that db2ldif
> needs the parentid attribute when the indexes are corrupted, but does
> it really need the _index_ parentid? I think db2ldif reads the entries
> directly from id2entry?
>    
Another good point.  I'm adding them to the ToDo list.  As you 
suggested, we may be able to eliminate the parentid index.   
Numsubordinates may not be (just my initial guess, though...)
> The questions concerning the interaction with other components of the server :
> some of server plug-ins assume that modrdn changes only the rdn part.
> These plug-ins will be broken. One of them is the
> referential integrity plug-in - it takes for granted that only the rdn
> part changes (update_integrity(argv, dn, newrdn, logChanges)).
> Other possible candidates are memberOf, linked attributes plug-ins,
> maybe some others. entryusn?
>
> Are there any repercussions on replication protocol and mechanism?
>    
I ran the test suite that covers these functionalities.  So far, I 
haven't seen any breakage.  But I might be missing something important, 
so your reviews would be greatly appreciated.

BTW, I've updated the patch at 
http://nhosoi.fedorapeople.org/0001-Allow-modrdn-to-move-subtree-and-rename-non-leaf-nod.patch 
.  It's sync'ed with the latest commit and it mentions about another new 
API slapi_dn_syntax_check.
- slapi_dn_syntax_check by nkinder at redhat.com is added to check the dn 
befor modify operations

Thanks,
--noriko

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6646 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.fedoraproject.org/pipermail/389-devel/attachments/20100114/fbb85bc6/attachment.bin