Gavin Henry wrote:

Julien Garnier wrote:

...

Gavin Henry a écrit :

...

Yes, as I thought. Translucent doesn't return searches on local attributes.

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 uid=foo and the local translucent entry containing cn=bar

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 results. 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.