[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: NEXTID (again!)

> At 12:45 PM 8/12/99 -0500, Randy Kunkee wrote:
> >If I simply run ldif2id2entry, NEXTID gets set correctly.  But I just
> >ran an ldif2ldbm -j 10 last night, and NEXTID ended up containing "1".
> >If ldif2id2entry is not doing this, what is?
> This can happen when ldif2id2entry fails to create the NEXTID
> file (for whatever reason) and slapd creates it on startup.

That explaination would work if I had started slapd, but I had not.
I had only run the ldif2ldbm.  I have noticed, however, that some
of the other tools use -lldif.  Perhaps in the process of initializing
they write a NEXTID value of "1".  If one of these programs did this,
and kept the file open, and then exited after ldif2id2entry (building dn
indices, or cn, or whatever), and then flushed the "1" on top of the
correct value, could this be the scenario?

If this is the case, then writing 1 into NEXTID if it does not exist is
not really a valid thing to do.  They should simply set NEXTID = 1
internally and not write the file.  Would there be a problem with this?

> Sure would be nice if someone would eliminate the NEXTID
> file (hint, hint).  This could be done by storing the
> "next id" in the id2entry database under key 0 with a
> value equal to next id.
> Kurt

So push NEXTID into the backend database.  Makes sense to me.