Re: schema checking

[dboreham@netscape.com (David Boreham)]

Hmm, I think I might be able to save
somebody some time here:

Roy Hooper wrote:

> ldif2ldbm does not check schema.  This is probably NOT a bug, but perhaps a
> developer will shed some light.

The original intent of the ldbm2ldif/ldif2ldbm duo was
to provide a way to move data _between_ servers,
and to perform a sort of backup. Hence, by definition
the data in the file would be correct since it would
have passed schema checking when it passed
through the LDAP protocol code.

Now, in the Netscape product we found that this
turned out to be pretty much incorrect.
ldif2ldbm was used to batch-build databases
from ldif files with extremely dubious contents.

So, over the years we tightened up checking
of the input data to the point where we now
(AFAIK) exhaustively check it. Certainly
we perform schema checking, check for the
existence of the parent entry.

Having done that, we then found that users
complained that their crusty old ldif files
which were incorrect were now rejected
by the server. So, in the latest version of
the code we attempt to only reject the
offending entries, not reject the whole file.

It was definitely possible to build a corrupt
database from a bad ldif file in the UMich code,
and that's a bad thing.

> As far as I understand it, ldif2ldbm doesn't check schema because the
> ldif2ldbm is generally used to contstruct a *NEW* database from what should
> be valid data, or to import an already existing database from another LDAP
> server.

Right, that's the reason. It's bogus, but it's the reason.

> You don't want to have ldif2ldbm check schema, because if it did, it's be
> much slower.

Mainly because the schema checking code is rather badly
written though :) If it were spruced up, you'd find that the checking
isn't a significant cost. You can always turn schema checking to
import a large file where you're 100% certain that it doesn't
violate schema.