On 24 avr. 2012, at 13:28, Emmanuel Lécharny 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)
I agree there should be a check during the creation of the entry (and move operations too, I guess). But, I think we also need to check for cycles during the evaluation of the search. If we use a batch insert mode with the server turned off to insert a large number of entries (even if we don't have such a possibility now, we might get it in a near future), we might have this kind of inconsistencies in the database. More importantly, if we don't have such a mechanism and we actually do get a cycle (for one reason or another, shit happens), the server would be looping forever and the user would have no other way than stop/restart the server (and pray for the same search request to never appears again). > 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 ? I had the same mechanism in mind. Costly, but at some point, you need this knowledge of what entries have already been returned. > 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… Sorry, I have no idea… :( Regards, Pierre-Arnaud > Many thanks ! > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.iktek.com >
