Re: (ITS#4817) modify "replace" command firing conflict error where it shouldn't be

> danielncsu.edu wrote:
>> Hi Howard!  As much as I hate to say this, it did
not solve the problem
>> I
>> was running into.  =(  I rebuilt openldap with the
entry.c patch and
>> rebuilt the LDAP database from scratch (pulling
from sources and using
>> slapadd).  Then I ran the following statement via
ldapmodify (as always,
>> XXX'd out sensitive info):
>
> The slapcat output you provide shows that the attribute
was already
> slapadded
> incorrectly. Please provide the "pulling from
sources" input you used with
> slapadd for this entry.

dn: uid=XXX,ou=students,ou=people,dc=ncsu,dc=edu
objectClass: person
objectClass: inetOrgPerson
objectClass: ncsuPerson
uid: XXX
cn: XXX
sn: XXX
title: Sophomore
ncsuTwoPartName: XXX
organizationalStatus: registered
o: NC State University
gn: XXX
ncsuMiddleName: XXX
initials: XXX
displayName: XXX
ncsuAltDisplayName: XXX
ncsuCampusID: XXX
ncsuClassCode: SO
ou: Political Science - Int Politics Conc
ncsuCurriculumCode: LIP
ou: B A - History
ncsuCurriculumCode: LAH
mail: XXX
ncsuPrimaryEMail: XXX
registeredAddress: XXX
postalAddress: XXX
telephoneNumber: XXX
l: Graham
st: NC
postalCode: XXX
ncsuPrimaryRole: student

Note that I have not changed anything to add the ou's as a
group and the
ncsuCurriculumCode's as a group, but from what I understood,
this should
work fine for openldap, even if it may or may not be truly
legit based off
the RFCs.  And again, I have not changed anything in this
code and have
been adding things like this for the past 2 years with
OpenLDAP 2.2 and
earlier.  I mean sure I can go edit my code to add those
ou's and
ncsucurriculumcodes in the correct order (ie, bunched
together), but if
you are saying openldap should be able to handle this, I'd
like to stick
with it and see it resolved instead of letting it be a
dangling difference
behavior since 2.2.  If you want to make an official-like
statement that
what I'm doing there is not proper and not supported, then
so be it, I'll
take that as golden and adjust my code.  =)  (in other
words, would you
rather it be that this is flat out not supported? .. of
course if it's not
supported it would be nicer if openldap yelled about it
instead of
accepting it and just being mad afterwards)

I moved away from 2.2 because it looks like you all don't
support it
anymore  and I started running into stability problems. 
(which we have
not narrowed down to be OpenLDAP's 'fault'..  just upgrading
OpenLDAP was
a good first and easy step 1, and actually seems to have
helped)

Daniel


> --
>    -- Howard Chu
>    Chief Architect, Symas Corp.  http://www.symas.com
>    Director, Highland Sun        http://highlandsun.com/hyc

>    OpenLDAP Core Team            http://www.openldap.
org/project/
>