Michael Ströder wrote:
Howard Chu wrote:
Seems like it would be a good idea to define a new option "glue-peer" or somesuch that allows multiple peer-level DBs to be glued together.
What exactly do you mean with peer-level DBs? I didn't get what the idea is for...
Mainly for grafting OpenLDAP on top of an existing, poorly designed someone-else's DIT.
In case of duplicate entries, we'd have to track them and either drop some of them or merge them.
Hmm...how about bind requests?
Good question.
I'm a very simple thinking guy. Therefore I'm not in favour of endorsing a setup which lets the slapd admins believe they don't have to think about schema and names spaces and consolidation of their data.
Also a good point.
How should duplicates be detected (by DN, by filter?) and based on which criteria should they be dropped or merged. Even merging is messy: Merge all attribute values of same attributes of all merged entries? Or give some entries priority over others or I'm already totally confused now... ;-)
Yeah, good questions. Perhaps it is better addressed by enhancing slapo-translucent instead to allow local entries to exist independently of remote ones. At least in that case, there is a clearly defined precedence. (All local data overrides any remote data.)