Major Description
It was mentioned in the parent task that the following can be accomplished when partitions can be nested which is synonymous with allowing multiple nexii which store data:
(6) The alias problem can be solved by a nexus that can store entries; it can consolidate and track alias indices across nested partitions.
Presently aliases are not allowed across partitions because entry ids are internal to a partition are specific to that partition. The system alias indices (3 exist) of a jdbm partition point to entries in a master table by id. There probably are several ways in which this can be fixed.
A Possible Approach
One approach is to expose the concept of the entry id as a unique number with server scope rather than partition scope. The server then can use this for various optimizations internally. Partitions would still use these values however they would be given them rather than creating them and the server would manage some entryId operational attribute through the operational attribute interceptor. The entry id is server specific and does not replace the use of a UUID.
This way the alias indices would still track links by entryId. However some aliases will not point into the current partition's master table. This is a problem. Hmmm. Need to think more about this. However the idea of pulling the search algorithm out of partitions into the server itself will have a major impact on how we implement a solution to this problem.
Also note that if an alias is encountered with dereferencing while searching then a part of the search must be delegated to the entry containing partition. This btw could even be done in parallel (cool). This is due to the fact that the system and user indices of the partition containing the alias do not have any records for the foreign entry so searches on indexed attributes will result in erroneous candidates.
This is a real hairy problem!!!