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

[Andrey Ivanov]

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. 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?

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.

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?

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?

Thank you for your efforts !