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:
HI!
Does the on-disk-format of back-mdb depends on which LDAP syntax is used for an attribute?
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.)
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.
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:
Michael Ströder wrote:
Does the on-disk-format of back-mdb depends on which LDAP syntax is used for an attribute?
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.)
I see.
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.
Changed how? LDAPModifying the schema definition in cn=config?
I'm using static configuration and therefore I just modified the schema file and restarted slapd.
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.
What does "inside slapd" mean with static configuration? It's stored in the MDB files?
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.
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.
Michael Ströder wrote:
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.
Just for the records: If the attribute value is first stored as DirectoryString syntax and attribute type is changed to Boolean syntax there does not seem to be a problem.
Ciao, Michael.
openldap-technical@openldap.org