Re: Some openldap fixes... (fwd) (fwd)

[Marijn Meijles <marijn@bitpit.net>]

You wrote:
> 
> Recycling IDs is currently viewed as being more dangerous (especially
> if not flushing key deletes).
> 
We only recycle if  the last ID is deleted. Furthermore id2entry is flushed
AFTER dn2id....

> upon values which had low occurrence rates (e.g. uid, mail).  Other
> accesses (requiring more expensive lookups) can be off loaded to
> other slaves configured for such.
True, but I feel off loading should not be an excuse for making ldap
smarter.
BTW, how much entries do you consider fucking huge?

> 
> Our out-of-box defaults are meant to be "reasonable" for "most"
> users.  As such, they should be tuned for mid-sized directories.
> Here, separate scoping and assertion indexes work well.  They
> are not overly expensive to maintain and are reasonably effective
> over common directory uses).  But maintaining N*M scoped keys
> (vs M assertion assertion key) gets quite expensive, especially
> if the tree is deep.
> 
I have the feeling you don't quite understand our algorithm. Like I
said in my previous mail, we ditched NM (which you still employ in 2.0
dn2id) EXACTLY because it's way too slow with deep trees.
Instead, we use a scheme which uses only one entry per attribute value, 
just like the old indices, but still has onelevel and subtree scoping.

> Again, it's all trade-offs.  There is not one "best way".  The
Nope, not in this case.

> 2.0 approach is okay for 90% of our users.  The other 10% might
> need to customize the code.  If those customizations are common
> place within the user base, we can include them in the distribution
> behind appropriate knobs.
To me this looks like a chicken and egg problem. Nobody will use
openldap for other stuff than flat (and possibly fucking huge) databases
like user databases as long as openldap is not good at handling deep trees.

Maybe it's an idea to create a patches page which is clearly visible (average
users don't look in mailing list archives or ITSs) to present new stuff
or contributed stuff which you don't want to put in the main tree.

For example, we changed the syncing a bit. If we hadn't done this, we would
not have used openldap. We are programmers, but what if we were not able
to fix that? We would probably have chosen another product. And we're not
the only ones who changed the syncing, given that this issue regularly 
surfaces on the mailing list.


-- 
Marijn@bitpit.net
---
If at first you don't succeed, destroy all evidence that you tried.