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);) @+ -- 389-devel mailing list 389-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-devel
