Le 4/24/12 2:22 PM, Pierre-Arnaud Marcelot a écrit :
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.
IMO, even if we provide a batch mode (which we have to provide in the
near future !), the we also must provide a check tool in order to be
sure that we haven't injected crap into the database.
Checking for cycle can be a costly operation...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
