[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: [EXTERNAL] Incosistent config after schema modification
- To: Quanah Gibson-Mount <quanah@symas.com>
- Subject: Re: [EXTERNAL] Incosistent config after schema modification
- From: Ervin Hegedüs <airween@gmail.com>
- Date: Wed, 10 Jan 2018 21:11:34 +0100
- Cc: Jon C Kidder <jckidder@aep.com>, openldap-technical@openldap.org
- Content-disposition: inline
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=UGn8OCnFbq4V/mC3PtNUF1DqYl/CK5QFI7itAlCXRIg=; b=cfamJI6FC6dy/ue3u3cQ36VmYjKDuGWXuqDzcmu620n9WS/945saf/5UVsBgGQL/ss fYnhw6yR1Am3LFFvy/MhpGZK7zyCaJqXtqGAZHSBQ2MG8Ttu5LzUqVQH0uGqouuBsj0B 1vjXSvV5USy3ydJuWC/84JSguAenMgMuKgrwxlAuxDq12jqsiz32gK1Y+qpc+tMzkOs3 1e/VGDkMFUw+ZyOxqXSXiAQRR9y/93Q6EnQMdw9kA4/ZQQES4/OKwPhxWhYzy3Cwvnig 6ZbfJHHmLq4z9BcMBM4ZTObLOP9cDiXhGRVCwVRxhoiYh2D+Ih0L9TopE/9oQXmcutNm rbnA==
- In-reply-to: <D970575B0F20D4A7B1AE5028@[192.168.1.30]>
- References: <20180110151655.GA23629@arxnet.hu> <677F33420B725A4D9E0066554451BDAC010663759D@VMAEPHQMS001.corp.aepsc.com> <D970575B0F20D4A7B1AE5028@[192.168.1.30]>
- User-agent: Mutt/1.5.24 (2015-08-30)
Hi Quanah,
thanks,
On Wed, Jan 10, 2018 at 10:24:22AM -0800, Quanah Gibson-Mount wrote:
> --On Wednesday, January 10, 2018 6:16 PM +0000 Jon C Kidder
[...]
> As a side note, you can delete specific values by using their weight, as
> well. For example:
>
> dn: <whatever>
> changetype: modify
> delete: olcAttributeTypes
> olcAttributeTypes: {7}
>
> Would delete the 8th attribute (since the weights are zero based)
>
> You can also use the weight to insert a value, like:
>
> dn: <whatever>
> changetype: modify
> add: olcAttributeTypes
> olcAttributeTypes: {7}( cppmAttrs:8 NAME 'cppmActivationTime' DESC 'Activati
> on time' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{20} SINGLE-VALUE )
>
> would insert cppmAttrs as the 8th value, and anything from what was the 8th
> value and up would be renumbered accordingly.
is there any relevant difference between the replace and
delete/add methods, which triggered this state in the DB?
What's the solution to avoid this?
Thanks,
a.