directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: Alias defereferencing: keep alias indices or not
Date Thu, 13 May 2010 13:56:21 GMT
Some elements of response :

- there is a RFC draft (an old one) describing how Alias should behave : 
http://www.opensource.apple.com/source/OpenLDAP/OpenLDAP-15/OpenLDAP/doc/drafts/draft-byrne-ldap-alias-xx.txt

(so far still a draft)
- Alias is described in section 2.6 of RFC 4512
- If an alias does not dereference to an existing entry, you'll get an 
AliasProblem result code

Now, how do we best handle this ?

The main two issues are :
- alias dereferencing must be fast
- we must be able to find cycle

We can detect cycle when modifying the base, and reject such a 
modification (can be costly though if doing a MODDN), or we can detect 
it when searching for a entry (can also be costly, and need extra 
storage to 'remember' whch entry we have gone through).

Another option of course is to not support Alias at all ;)

  More inline...

On 5/13/10 3:29 PM, Stefan Seelmann wrote:
> Hi
>
> I'd like to fix the various issues we have with alias handling [1]-[4].
>
>
> Right now we are using indices for alias handling. When using indices it
> is essential that they are of integrity. It is important that the target
> of an alias entry (referenced by aliasedObjectName) exists. We check
> this when adding an alias entry. However when deleting, moving or
> renaming the target entry we have issues: the alias entry points to an
> non-existing target and the alias indices are not updated.
>    
Which is not necessarily a problem.
>
> I'd like to discuss whether to keep those aliases or to use an
> alternative approach for alias dereferencing.
>
>
> Here are the pros and cons of alias indices from my POV:
>
> Pros:
> - very efficient alias dereferencing at search time using alias indices
> and cursors
>    
yop
> - no duplicate search results, i.e. elimination of duplicates is built-in
> - no loops can occur, i.e. loops are detected on write time
>    
yop.
> Cons:
> - cross-partition aliases are not supported atm (can be fixed)
>    
Complicated, but yes.
> - alias chaining is not supported
>    
It should ! If it's not supported, then the current index are ot wll used.
> - indices must be maintained on write time
>    
yop, but it's best to do that at write time, as you will have many read 
for one single write
> - target entries must exist before adding alias entries for them, makes
> LDIF export/import more difficult
>    
yes, and that's a problem. i'm not sure we should enforce that.
> - alias dereferencing must be implemented for each partition
>    
yes.
> If we keep the alias indices we need to fix the issues I described
> above, possible solutions are:
> 1. Reject delete/rename/move operations of an entry, if any alias points
> to this entry.
>    
No way. It's legal.
> 2. Automatically update alias entries and indices:
> 2.1 When deleting an entry we need to delete all alias entries that
> point to that entry.
>    
No. Still legal to have aliases pointing to nothing.
> 2.2. When moving/renaming an entry we need to update the
> aliasedObjectName value of all alias entries that point to the entry.
>    
No. Its legal.

In fact, if we delete the entry whch is dereferenced, then the aliases 
will point to nothing, but that's not the server problem, it's the user 
problem.

We could though offer an extended operation that find all the bad 
aliases, so that the base can be fixed...



-- 
Regards,
Cordialement,
Emmanuel L├ęcharny
www.nextury.com



Mime
View raw message