On Tue, Jun 14, 2011 at 12:19 AM, Stefan Seelmann <seelm...@apache.org> wrote: > On Mon, Jun 13, 2011 at 11:12 PM, Emmanuel Lécharny > <elecha...@apache.org> wrote: >> On 6/13/11 10:12 PM, Howard Chu wrote: >>> >>> Ludovic Poitou wrote: >>>> >>>> Sun Directory Server, OpenDS, OpenDJ, Port 389 (formerly known as Fedora >>>> Directory) at least, do not support Alias dereferencing because the >>>> complexity >>>> out-weights the benefits, and very few client applications make use of it >>>> anyway. >>>> >>>> My 2 cents. >>> >>> We had no alias support in back-bdb originally; I added it back in 2003. >>> >>> Indeed, you only need to track all of the alias entries that you hit, and >>> that's typically a small number. Each new entry defines a new search scope. >>> Any time a dereference leads to an entry that resides anywhere within your >>> already-known search scopes that deref can be considered fully resolved, >>> because the result was already part of the scope. >> >> This is teh algorithm I foresee too. > > +1 > >>> >>> It's actually quite simple and quite fast. Using the objectclass index >>> it's trivial to obtain the list of all alias entries within the database, so >>> from the outset you already know the maximum size of what you're dealing >>> with. >> >> We already have a cache that is constructed at startup, gathering all the >> aliases from the backend, using the OC index. This cache is of course >> updated on the fly, if one alias is added or removed. >> >> I don't think it should take more than one day to fix this issue. > > In that case we can also get rid of all the alias indices (aliasIdx, > oneAliasIdx, subAliasIdx).
This would be a big mistake. Then you'd be better off just getting rid of aliases all together. You don't know how many aliases you'll have at the end of the day and presuming some number is making presumptions on behalf of the user even if aliases in practice are not used.
