[389-devel] Please review: [Bug 557224] subtree rename breaks the referential integrity plug-in

[Noriko Hosoi]

Hi Andrey,

You are right.  Sorry, I haven't tried the subtree rename case...  Let 
me investigate it some more.

On 01/26/2010 01:23 PM, Andrey Ivanov wrote:
> Hi Noriko,
>
> Thank you for your patch. The patch you provided does take into
> account the modRDN with new superior but it does not seem to take care
> of subtree renames (smth like rename "ou=users" to "ou=utilisateurs"
> with child entries). For subtree renames all the entries in the
> renamed subtree change their DNs so  for each  of these renamed
> entries we have to make the search
> "slapi_search_internal_set_pb(search_result_pb, search_base,
> LDAP_SCOPE_SUBTREE, filter, attrs..." with a different filter.
> So for each modrdn we should verify if the renamed entry has any child
> entries and if it is the case then treat them either directly or
> recursively...
>
> As for the modrdn with newsuperior part i have a question : if
> newsuperior=NULL you take the parent of the original entry
> slapi_dn_find_parent(origDN) (btw, i haven't found this function in
> RHDS plug-in documentation). What does this function return for the
> base suffix? Or any rename/move operations are forbidden for the
> suffix?
>    
We don't allow rename/move the suffix.  I've just tried that and got 
unapproriate errors depending upon the newrdn.  They need to be fixed...
ldap_rename: Invalid DN syntax
ldap_rename: additional info: invalid RDN

ldap_rename: DSA is unwilling to perform
ldap_rename: additional info: Cannot move entries accross backends

*Bug 559016* <https://bugzilla.redhat.com/show_bug.cgi?id=559016> - 
Attempting to rename suffix returns inappropriate errors

Thanks,
--noriko
> 2010/1/26 Noriko Hosoi<nhosoi at redhat.com>:
>    
>> https://bugzilla.redhat.com/show_bug.cgi?id=557224
>>
>> Description of problem:
>> Analysis by andrey.ivanov at polytechnique.fr
>>      
>>> 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...
>>
>> Fix Description: The referential integrity plugin has not supported
>> the subtree rename (modrdn with newsuperior).  This patch is adding
>> the support.
>>
>> Created an attachment (id=386896)
>> git patch for ldap/servers/plugins/referint/referint.c
>>
>> --
>> 389-devel mailing list
>> 389-devel at lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/389-devel
>>
>>      
> --
> 389-devel mailing list
> 389-devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-devel
>    

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/389-devel/attachments/20100126/5273d793/attachment.html