Gavin Henry wrote:
Julien Garnier wrote:
> Gavin Henry a écrit :
>> Yes, as I thought. Translucent doesn't return searches on local
>> One for the to do list then.
Yes... The original spec for this overlay only required the ability to search
the remote DB. Searching both requires quite a lot more work.
One sticking point is that search filters need to be munged; if you send a
filter to the remote server and it mentions attributes that are only known on
the local server, then you may not get any results back at all. (And vice versa.)
E.g., if you have a remote entry containing
and the local translucent entry containing
and you search for (&(uid=foo)(cn=bar)) then the search will return no results
unless you rewrite the filter on both the local side and the remote side.
A solution here would be to add config keywords to control how filters should
be handled. For any attribute used in a filter, it may be remote only, local
only, or both local and remote.
The processing would go something like -
for the remote search, walk through the filter and nullify any clauses that
aren't in the list of remote attributes. If the filter collapses down to
nothing, skip the remote search. Otherwise, execute the search and keep a list
of the results.
for the local search, process the filter as above; if the filter collapses,
skip the local search. Otherwise, execute the search and keep a list of the
for each entry in the remote list, look for a corresponding entry in the
local list and the local DB. Merge the entries.
for each entry in the local list, do likewise.
merge the lists
reprocess the list using the original filter.
Quite a lot of steps.
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/