On Tue, Apr 24, 2012 at 4:58 PM, Emmanuel Lécharny <[email protected]> wrote: > Hi guys, > > Aliases handling is one of the biggest challenge in LDAP, as it imposes a > lot of constraints. First of all, keep in mind that Alias support is not > mandatory. > > Some of the problem we have when dealing with Alaises are : > - cycle detection : we should not allow the creation of an alias that causes > a cycle > - duplicated entry removals in searches : we shuld not return an entry that > has already been returned > - unlinked aliases : when the aliased entry is removed, we should should > handle it > - subtree searches with aliases : we may have a very high nunber of entries > to return > - move operation : how do we handle the aliases modification when the > aliased entries is move ? > - cross-partitions aliases : how do we handle them ? > - replication of aliases > > Right now, my concern is about duplicated entries removal and cycle > detection, during a search processing : > > 1) Cycle detection : > Should we assume that the cycles are detected during the alias creation ? Or > should we detect it while processing the search ? (I'm nclined to think that > cycle are forbidden during their creation) > > 2) duplicated entries removal > I don't see any other way but storing a hash of all the UUID we already have > transmitted, and to check when we have a new candidate if this candidate has > already been processed. This is potentially *extremely* costly, if we have > millions of entries (even if there is a size limit, which protects us from a > OOM, because this size limit is not enforced for the manager user). > Is there a better way ? > > 3) Current Aliases index > I didn't have time to check what those index are used for, so if someone can > give me a quick heads up, that would save me a few days of code diging... > this is used exactly for solving the above mentioned 'cycle detection' problem > Many thanks ! > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.iktek.com >
-- Kiran Ayyagari
