https://bugs.openldap.org/show_bug.cgi?id=10411

Issue ID: 10411 Summary: Seems like importing data with slapadd does not create the structuralObjectClass OpAttr when -s flag is used Product: OpenLDAP Version: 2.6.10 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs@openldap.org Reporter: elecharny@apache.org Target Milestone: ---

When exporting entries with a slapcat and removing all the opAttrs, keeping the bare entries with only user attributes, then importing them with slapadd creates entries without the structuralObjectClass attribute, when using the -s flag.

Which leads to en error 80 'No structuralObjectClass Operation Attribute' when trying to modify an injected entry.

(I'll check if this was the standard behaviour un 2.4/2/5=)

Two remarks: - the structuralObjectClass should be added no matter what, assuming it's correct (ie the objectclass hierarchy is sane) - and even if it's not created, there is no reason to get a error 80 when modifying the entry: the structuralObjectClass should be added when a modify operation is applied (all in all, it's an OpAttr, up to the server to deal with it).

Here is the added entry:

version: 1 dn: o=service,o=worteks objectClass: organization o: service description: One entry #structuralObjectClass: organization

When removing the -s flag, all works fine.

Note: the reason I was using the -s flag is that I wanted to squeeze as much performance as possible when injecting 30M entries. The gain may be minimal (like 4 s when injecting 10M entries - 1m9 vs 1m13) , but still.