[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: partial replication of entries/attributes

I am about to commit a "partial replication" patch to the HEAD.
This patch adds a "attr=<attribute list>" keyword to the replica directive.
If specified, then only attributes in the given list will appear in the
for the given replica. If an operation occurs that doesn't affect any of the
listed attributes, no log is generated.

Since this list affects both adds and modifies, it would be worthwhile to
ensure that "objectclass" is always on this list if it's used at all.
Otherwise you could add an entry that is completely ignored, but later have
a modify come along that references the entry. (The replication would fail
since the slave never saw the add.)

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support

> -----Original Message-----
> From: owner-openldap-devel@OpenLDAP.org
> [mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Randall S.
> Winchester
> Sent: Thursday, January 10, 2002 1:51 PM
> To: Pierangelo Masarati
> Cc: hyc@highlandsun.com; openldap-devel@OpenLDAP.org
> Subject: Re: partial replication of entries/attributes
> 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.
> Randall