On Sat, 2005-11-12 at 17:23 -0800, Howard Chu wrote:
Pierangelo Masarati wrote:
Is local addition intended to be supported? Yes, apparently, according
to the man page; but I note this case is not tested in test034. So my
question is: does my approach make sense, should this be possible and
it's not happening because of a bug, or is my design flawed?
No, the current design of the translucent overlay does not allow totally
local entries to exist. I.e., there must be a corresponding remote
entry. Also, it expects the local and remote DB to have the same suffix.
After looking at the code, and thinking myself about its design, I
realize it likely doesn't fit the purpose. In fact, even though the
local entries are present (and they __are__, as if I comment out the
translucent stuff they actually get returned by the local database) they
cannot be reached because no local search is performed, but only entry
lookups based on the DNs resulting from the remote search (which sounds
likely and, I'd say now, obvious :). One drawback of this, that makes
slapo-translucent unfit for my purpose, is that local attributes cannot
appear in search filters; too bad.
This is consistent with the results of my speculations about a meta-
engine that merges entries, including searches. If we could speculate a
bit more on searches, e.g. specifying which attributes should be only
searched locally, which should be only searched remotely, which at both
sides, and then do some local merging of the results to track the
duplicate DNs, this would fit my current needs. In terms of server load
and performances it might be even worse than server side sorting, but
it's likely the only solution in cases where I need to augment data from
a remote server which I cannot write and in some cases I cannot even
entirely read.