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

[Gary Williams <Gary.Williams@sas.com>]

I for one would really like to see any changes that make
the ldbm backend faster and more reliable.  Perhaps a more
detailed explanation of your scoping algoritm?

> -----Original Message-----
> From: Marijn Meijles [mailto:marijn@bitpit.net]
> Sent: Tuesday, September 19, 2000 7:12 AM
> To: openldap-devel@OpenLDAP.org
> Subject: Re: Some openldap fixes... (fwd) (fwd)
> 
> 
> 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.
>