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.
