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);)
@+