Re: partial replication of entries/attributes

[Pierangelo Masarati <masarati@aero.polimi.it>]

> On Thu, 10 Jan 2002, Pierangelo Masarati wrote:
> 
> : > In LDAP/X.500, modifications are atomic, all-or-nothing. If any part of an
> : > update fails the entire update must fail. The place to limit things is on the
> : > master, when it generates the replog.
> :
> : I definitely meant using some sort of ACLs when generating the replog
> : data, a sort of extension/generalization of the current code that
> : partially replicates a subtree.  One could think of generating only
> : partial changes based on some rule; ACLs may be one flexible way to
> : write those rules.
> 
> If you mean like the "filter replicas" some vendors offer, I think
> this would be just dandy.

I'm not sure what "dandy" means, so I'll take it as a compliment ;)

The subtree partial replication came out of some (few) user's demand;
I implemented it because I thought I needed it too, but I haven't used 
it yet; in fact I usually prefer to have one extra full replica around
(for reliability and more) that maintaining many specific partial 
replicas; moreover, while subtree makes sense because data integrity
is preserved in the subtree, "filtered" replica would be useful only
in very specific cases (e.g. not replicating sensible info to unsecure
replicas, or replicating portions of very complex iand frequently 
updated entries to a slave that does only very specific tasks, think 
of a server that routes millions on mails per day so it is unlikely 
to serve other applications but sendmail).

However, if there's demand it won't be a big problem to put in place
a simple yet flexible filtering.

Pierangelo.