[Date Prev][Date Next]
Re: Syncrepl nits with operational attributes (ITS#3289)
> At 12:37 PM 8/19/2004, email@example.com wrote:
> >Maybe better would be for syncrepl to have a hardcoded list of
> >attributes that it ignores - e.g., all values that we know are
> >dynamically generated (like hasSubordinates) and all values that are
> >DSA-specific (e.g. subschemaSubentry), so that attrs=*,+ will work
> >without hassles.
> This is my preference. The slave should be able to right
> thing with everything (atrrs=*,+) as well as anything
> (any subset of the above -- e.g., factional replication).
Looks like the important part is the definition of the right thing. The
"everything" case was resolved with the SLAP_AT_DYNAMIC flag in the Howard's
patch. For the fractional replication case, the current behavior is to let
the user specify operational attributes to replicate other than what are
absolutely necessary (objectClass, structuralObjectClass, entryCSN, and
entryUUID). This is because if we add additional operational attributes, we
will need a mechanism to exclude the ones a user does not desire to
replicate (as in "attrs=!foo"). If this exclusion scenario can be considered
as a corner case, it would make sense to include additional operational
attributes which are commonly required to be replicated.