HI!
Does the on-disk-format of back-mdb depends on which LDAP syntax is used for an attribute?
So if the LDAP syntax for an an existing attribute would change I have to reimport the MDB?
Background:
I've changed (as a work-around for a broken client software) the LDAP syntax of a custom attribute from Boolean to IA5String.
After that I could still read the attribute. But when deleting the attribute slapd returned noSuchAttribute(16). I had to remove the whole entry.
BTW: No index configured this attribute.
Ciao, Michael.
Michael Ströder wrote:
In multiple ways. Indexing depends on the syntax and matching rule, but you already mentioned no indexing here. Also, whether or not the syntax uses a normalizer inside slapd or not, determines how values are stored in an entry. (With a normalizer, values are stored twice, once in normalized format.)
Changed how? LDAPModifying the schema definition in cn=config?
After that I could still read the attribute. But when deleting the attribute slapd returned noSuchAttribute(16). I had to remove the whole entry.
Most likely your change created two clashing AttributeDescriptions inside slapd. Internally, attributes are matched by their AttributeDescription pointers, not by their string names. If you changed the attribute definition by deleting and adding it, then there would be two AttributeDescription pointers for the same name, and an entry loaded with the old pointer would naturally not match a lookup for the current pointer.
BTW: No index configured this attribute.
Ciao, Michael.
Howard Chu wrote:
I see.
I'm using static configuration and therefore I just modified the schema file and restarted slapd.
What does "inside slapd" mean with static configuration? It's stored in the MDB files?
Example entry created with msTestAttributeType3 declared as Boolean:
dn: uid=test,dc=example,dc=com msTestAttributeType2: foo msTestAttributeType3: TRUE objectClass: account objectClass: msTestObjectClass2 uid: test
After changing declaration of msTestAttributeType3 to e.g. SUP name this change results in noSuchAttribute(16):
dn: uid=test,dc=example,dc=com changetype: modify delete: msTestAttributeType3 msTestAttributeType3: TRUE - add: msTestAttributeType3 msTestAttributeType3: FALSE -
This modification works (not the missing delete value):
dn: uid=test,dc=example,dc=com changetype: modify delete: msTestAttributeType3 - add: msTestAttributeType3 msTestAttributeType3: FALSE -
It seems the normalized values are used when processing delete-by-value.
Ciao, Michael.
openldap-technical@openldap.org