Re: slaptest-ldif -l <ldif> tool or slapadd option

[Hallvard Breien Furuseth <h.b.furuseth@usit.uio.no>]

On 25. mars 2015 00:56, Emmanuel Lécharny wrote:
> Le 24/03/15 23:56, Howard Chu a écrit :
> > Hallvard Breien Furuseth wrote:
> > > I'd like a slap tool which verifies an LDIF before I try to
> > > ldapadd/slapadd it.
> > > "slapadd -u -o value-check=yes" is fairly close.  What does it fail
> > > to catch?
> > > I can think of:

Another requirement:

- An attribute should not occur several times in an entry with
  other attributes in between.  E.g. "cn", "title", then "cn".
  That gives broken entries at least with slapadd -q.

> > > - Duplicate entries.
> >
> > Quite an unrealistic requirement. You need to store the set of
> > entryDNs to achieve this, and for a large LDIF you may need an actual
> > database to manage this. Might as well just do a normal slapadd.

No, I want it to be faster than that.  Also I might do someting else
with the verified LDIF anyway.  Generate a diff against the current DB
and feed it to ldapmodify.

DN checking would need to be an option, which could just document
"you asked for unbounded memory usage, you got it".  Though I suppose
it could slapadd to a DB with just the DNs, not any attributes.

> Let me disagree. A simple merge sort will do the trick. No need of a
> database to deal with that, even for a large LDIF. We have done some
> tests with the tool we use to handle bulkloads at ApacheDS, and that
> works quite fine, and quite fast enough.

Nice idea.

A reliable sorter would still need to link slapd or something else
knowing the schema though, so it'll normalize the DNs correctly.  Not
quite sure if I'll bother to worry about that.  Don't need it with
LDIFs we generate ourselves, but LDIFs from elsewhere are less fun.

--
Hallvard