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

[Andrey Ivanov]

Hi,

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

Ok. That's what I've thought. Howard also confirms and explains this
in his mail.


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

I'm pretty sure the referential integrity plug-in will not work for
modrdn operations with a new superior. Looking more thoroughly through
the code ( ldap / servers / plugins / referint / referint.c) confirms
my suspicion that new rdn superior is not taken into account. The
function  referint_postop_modrdn extracts from the parameter block
only SLAPI_MODRDN_TARGET and SLAPI_MODRDN_NEWRDN, it does not extract
SLAPI_MODRDN_NEWSUPERIOR neither passes it further down the utility
functions - update_integrity(argv, dn, newrdn, logChanges) and
writeintegritylog(argv[1],dn, newrdn). The same applies to the delayed
referint operations (the plug-in writes to the special integrity log
file only the old DN and the new RDN, but never the new superior :
writeintegritylog(argv[1],dn, newrdn);)

@+