10:20 a.m.
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.
12:12 a.m.
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
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
10:06 a.m.
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.
10:30 a.m.
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.
3225
days inactive
3226
days old
openldap-technical@openldap.org
3 comments
2 participants
participants (2)
-
Howard Chu -
Michael Ströder