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

Andrey Ivanov andrey.ivanov at polytechnique.fr
Mon Jan 18 19:35:46 UTC 2010


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

Another thought on the subject of referential integrity plug-in - in
the previous mail i have only mentioned one-entry renames with a new
superior. The things get even worse when we rename a whole non-empty
sub-tree. It means that the referential integrity plug-in should
change to the new DNs all the references to all the entries of the
whole sub-tree, not only for one entry.

And what if we rename a sub-tree containing both the referenced entry
and the entry referencing the first one's DN in one of its "integrity"
attributes? It actually means that we need at first make the rename
and then all the searches and replacements. Though it seems it's
already the case as it's a post-op(?) plug-in...


More information about the 389-devel mailing list