[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: LDIF parser performance
Michael Ströder wrote:
How does that sound to you? I'm not sure what different actions
ldapadd -n does in comparison to my simple script. But at least
count_members.py also reads the complete entries into a tuple containing
the DN as string and the entry as so-called dictionary.
Sounds about as expected, the client side really hasn't gotten much
attention as far as performance goes.
I just noticed something else, which I'm hesitant to call a bug, since
RFC2849's grammar doesn't actually forbid it.
ldapmodify will accept multiple modifications without a separator in
between them. E.g.:
dn: dc=example,dc=com
changetype: modify
add: cn
cn: foo
sn: bar
description: xyzzy
All of the examples show that the attrval-spec's in the mod-spec show
matching AttributeDescriptions, but nothing in the grammar says they
must match. The above LDIF will create a valid request to add the 3
different attribute values to the target entry.
The examples imply a particular intent, but there's nothing in the
grammar that dictates this intent. Obviously the AttributeDescription in
the mod-spec is redundant in all cases except when deleting all of the
values of an attribute. (Did I mention that I've always thought the
mod-spec definition was garbage? The format I use for the logschema has
none of these problems or inefficiences...)
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/