directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre-Arnaud Marcelot ...@marcelot.net>
Subject Re: Server-integ tst faiure : a question
Date Tue, 03 Jan 2012 08:52:42 GMT

On 3 janv. 2012, at 09:01, Pierre-Arnaud Marcelot wrote:

> 
> On 3 janv. 2012, at 08:49, Kiran Ayyagari wrote:
> 
>> On Tue, Jan 3, 2012 at 5:55 AM, Emmanuel Lecharny <elecharny@gmail.com> wrote:
>>> Hi,
>>> 
>>> I'm facing an interesting issue :
>>> - we are trying to add a new entry
>>> - this entry has a RDN which is a SingleValue AT (DisplayName)
>>> - there already is a DisplayName Attribute present
>>> - the RDN and the present value are different.
>>> 
>>> Here is the entry :
>>> dn: displayName=test,ou=system
>>> objectClass: top
>>> objectClass: person
>>> objectClass: inetOrgPerson
>>> objectClass: organizationalPerson
>>> displayName: Michael
>>> sn: Michael Jackson
>>> cn: Jackson
>>> 
>>> (displayName is a SingleValue AT)
>>> 
>>> In trunks, the entry is added, and the existing Attribute is removed, and
>>> replaced by displayName: test
>>> 
>>> In Selcuk's branch, due to some modifications I've done recently in the way
>>> we normalize added entries, we get an exception.
>>> 
>>> Now, it leads  a question : should we accept the entry, modifying it on the
>>> fly, or should we reject the addition ?
>>> 
>>> IMHO, I do think that accepting the entry as is would lead to a violation of
>>> the user's will : ie, the risk is that the user has made a mistake when
>>> describing the entry, and should be informed about this mistake, instead of
>>> 'reparing' the mistake.
>>> 
>>> wdyt ?
>>> 
>> +1, it should fail, OTOH I assume that this is already the case when
>> added using Studio (haven't tried now, but I remember experiencing
>> this situation)
> 
> +1

Quick followup.

I did the test with the current Apache Directory Studio (trunk):

- On Apache DS (trunk) the addition of the entry is successful.
The value used in the DN is chosen and replaces the value in the entry.

Here's the LDIF used:
> dn: displayName=test,ou=system
> objectClass: top
> objectClass: person
> objectClass: inetOrgPerson
> objectClass: organizationalPerson
> displayName: Michael
> sn: Michael Jackson
> cn: Jackson


And the output in Studio's Modification Logs view:
> #!RESULT OK
> #!CONNECTION ldap://localhost:10389
> #!DATE 2012-01-03T08:06:09.661
> dn: displayName=test,ou=system
> changetype: add
> displayName: Michael
> objectClass: top
> objectClass: person
> objectClass: inetOrgPerson
> objectClass: organizationalPerson
> sn: Michael Jackson
> cn: Jackson


- On OpenLDAP (2.4.24) the addition of the entry is not successful.

Here's the LDIF used:
> dn: c=TE,dc=my-domain,dc=com
> objectClass: top
> objectClass: country
> c: FR

And the output in Studio's Modification Logs view:
> #!RESULT ERROR
> #!CONNECTION ldap://10.211.55.4:10389
> #!DATE 2012-01-03T08:40:57.117
> #!ERROR [LDAP: error code 64 - value of single-valued naming attribute 'c' conflicts
with value present in entry]
> dn: c=TE,dc=my-domain,dc=com
> changetype: add
> objectClass: top
> objectClass: country
> c: FR

The result on OpenLDAP makes more sense I guess.


> Regards,
> Pierre-Arnaud
> 
>>> (FYI, the failing test is in server-integ, AddIT,
>>> testAddEntryDifferentRDNSingleValuedInEntry())
>>> 
>>> --
>>> Regards,
>>> Cordialement,
>>> Emmanuel L├ęcharny
>>> www.iktek.com
>>> 
>> 
>> 
>> 
>> -- 
>> Kiran Ayyagari
> 


Mime
View raw message