[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: [EXTERNAL] Incosistent config after schema modification

Hi All,

Jon, thanks for the reply,

My first (off-topic) question: why did my e-mail came as
"EXTERNAL"? Before I sent it, I've checked myself, and looks like
I'm member of this list...

On Wed, Jan 10, 2018 at 06:16:59PM +0000, Jon C Kidder wrote:
> To replace individual values of a multi-valued attribute you must
> explicitly delete the old value and then add the new one in
> the same transaction.  You cannot use a replace operation to
> replace individual values of a multi-valued attribute.  The
> replace operation removes all pre-existing values.  After loading
> your ldif your custom schema will only contain the 3 attributes
> included in your ldif.   All of your other custom attributes will
> be gone.

those attribute types are SINGLE-VALUE's. I don't understand
this part of your answer.

> At this point you will need to create and load a new ldif that
> will add all of the missing attribute definitions.  When I
> modify a custom schema I use the replace operation but my ldif
> contains all of the object class and attribute type definitions
> related to that schema.  This way the schema can be maintained
> as a versioned artifact in my version control system.

yes, I've found the solution as you descibed here.

But I'm curious, why occured this state in the DB?

When I run the ldapmodify, the modification replicated
immediatelly to all nodes of cluster, and all db came as
incosistent.

IMHO the expected result would be an error, when I run the
ldapmodify command with these ldif.

Thanks again,


a.