directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Zoerner <ste...@labeo.de>
Subject Re: [jira] Commented: (DIREVE-173) On modifyRdn server now adds additional Rdn attribute
Date Thu, 11 Aug 2005 13:34:57 GMT
Hi Trustin!

Here is an example for the first case.

-----------

# create an entry for a person
#
dn: cn=Myra Ellen Amos,dc=example,dc=com
changetype: add
objectclass: top
objectclass: person
cn: Myra Ellen Amos
sn: Amos
description: an American singer-songwriter

# Change RDN
# old RDN value of cn should continue to be in place
#
dn: cn=Myra Ellen Amos,dc=example,dc=com
changetype: modrdn
newrdn: cn=Tori Amos
deleteoldrdn: 0

# Change RDN a second time
# old RDN value of cn should continue to be deleted
#
dn: cn=Tori Amos,dc=example,dc=com
changetype: modrdn
newrdn: cn=Myra E. Amos
deleteoldrdn: 1

-----------

I applied it to IBM Tivoli Directory Server 5.2 (just to be sure) and 
the result (after both modrdn) is:

dn: cn=Myra E. Amos,dc=example,dc=com
objectclass: top
objectclass: person
cn: Myra Ellen Amos
cn: Myra E. Amos
sn: Amos
description: an American singer-songwriter

I think it is logical. The first modrdn adds a value to cn and does not 
delete the old value of the cn.
Therefore, Tori has two values for attribute cn after the first modrdn, 
one of them forms the rdn "cn=Tori Amos", the other "cn=Myra Ellen Amos" 
does not (cn allows multiple values).

The second operation adds a new value for cn ("cn=Myra E. Amos"), uses 
it as the new rdn, and deletes the attribute value of the old rdn 
("cn=Tori Amos").
As a consequence, the attribute value "cn=Tori Amos" is gone, but 
"cn=Myra Ellen Amos", which was not part of the rdn not.

The point here is that cn allows multiple values. Behavior is different 
otherwise.

I hope this helped -- Greetings from Hamburg,
    Stefan

Btw.: Just another example why a test suite for all basic protocol 
operations would be worthwhile. I work on a first version of  using 
JNDI. But I already faced some (minor) problems, because some LDAP 
operations are very difficult to simulate with JNDI (obviously not the 
idea of a protocol test suite, to use work arounds ...).



Trustin Lee (JIRA) wrote:

>    [ http://issues.apache.org/jira/browse/DIREVE-173?page=comments#action_12318447 ]

>
>Trustin Lee commented on DIREVE-173:
>------------------------------------
>
>Stefan,
>
>What happens if user first modifies RDN without deleting old RDN and then modifies RDN
again with deleveoldrdn=1?
>Should LDAP server delete all RDNs which were not deleted by the first operation in the
second operation?  What if the new RDN of the second operation was not 'cn' but 'ou' or 'dc'?
>
>  
>
>>On modifyRdn server now adds additional Rdn attribute
>>-----------------------------------------------------
>>
>>         Key: DIREVE-173
>>         URL: http://issues.apache.org/jira/browse/DIREVE-173
>>     Project: Directory Server
>>        Type: Bug
>>  Components: jdbm database, jndi-provider
>>    Versions: 0.9.1
>>    Reporter: Alex Karasulu
>>    Assignee: Trustin Lee
>>    Priority: Blocker
>>    
>>
>
>  
>
>>I changed the name of an entry like ou=Users, dc=example, dc=com to ou=users, dc=example,
dc=com which had a single ou=Users.  I expected this operation to delete the old attribute
rather then just add the new one.  This can become a serious issue hence the reason why  its
a blocker.
>>    
>>
>
>  
>




Mime
View raw message