directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Seelmann <>
Subject Alias defereferencing: keep alias indices or not
Date Thu, 13 May 2010 13:29:56 GMT

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.

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:

- very efficient alias dereferencing at search time using alias indices
and cursors
- no duplicate search results, i.e. elimination of duplicates is built-in
- no loops can occur, i.e. loops are detected on write time

- cross-partition aliases are not supported atm (can be fixed)
- alias chaining is not supported
- indices must be maintained on write time
- target entries must exist before adding alias entries for them, makes
LDIF export/import more difficult
- alias dereferencing must be implemented for each partition

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.
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.
2.2. When moving/renaming an entry we need to update the
aliasedObjectName value of all alias entries that point to the entry.


As an alternative I have the following idea: A special cursor
implementation, used in DefaultPartitionNexus, that performs aias
dereferencing at search time. It adds an or'ed (objectClass=alias)
filter to the original search request. For each alias entry returned by
the underlying partition's search operation it starts a new search.

- no need to implement alias dereferencing for each partition
- allows alias dereferencing accross partitions
- allows chained aliases
- no problem if alias target doesn't exist as the sub-search just
doesn't return any result

- the main problem is that a new search must be started for each alias
entry in search scope. The more alias entries we have in the server the
slower a search becomes.
- to avoid loops and duplicate search results it is necessary to track
the base and scope for each performed sub-search.


Kind Regards,


View raw message