[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/