Re: Some openldap fixes...

[kunkee@neosoft.com (Randy Kunkee)]

At 07:12 AM 9/19/00 -0700, Kurt wrote:
>At 02:09 PM 9/19/00 +0200, Marijn Meijles wrote:
>>You wrote:
>>The only point I'm
>>trying to make is that we may have different points of view on what to
>>enhance and in what way.
>
>That's my point as well.
>
>>> Working with contributors is fun.
>>Then please look at our code, because you're making some wrong assumptions
>>about it.
>
>I have looked at your code and I agree that I'm likely making all
>kinds of wrong assumptions.  It's 85k of diff against old code
>covering numerous issues.... (and my mind is on 2.0).  Distilling
>what might be useful in terms of current code is an difficult task.
>
>>We've also looked quite closely at your code ;)
>
>Good.  I hope we can start addressing the issues in terms of the
>current code.  You're post detailing indexing is a good start.
>
>Kur

I like many of the changes that you have made.  I think it would
be valuable to get them into 2.1.  I would have it be earlier, but
since it would require a dump and reload of the database, it should
be in a major release.

I do take exception to the NEXTID solution you have.  It seems that
some dangeous kinds of corruption could occur if an index file is
pointing to a deleted id2entry record and you reuse that ID, that's
a problem.  I doubt that you check all the index files, since you'd
have to scan them too.  Haven't looked at your code, but I don't
see how you can avoid scanning the entire id2entry list of keys
to make sure you have the highest one.  Isn't that expensive, especially
for the f*ing huge databases we're discussing here :-).  I have a
few hundred thousand in mine.

If you can break up your changes into individual categories (NEXTID,
indexing, syncing, for example) and prepare changes against the current
HEAD branch, then we'll have a much better chance of being able to
digest them.  In those cases where agreement is less than unanimous,
we can either agree to hide them behind #ifdefs or leave them as
separate patches on the side (which I'd prefer as little of as possible).

Randy