[PATCH] Schema replication

[Kamen Mazdrashki]

Hi Metze,

Thanks for your comments!

On Fri, Dec 10, 2010 at 11:11, Stefan (metze) Metzmacher
<metze at samba.org> wrote:
> Am 10.12.2010 03:54, schrieb Kamen Mazdrashki:
>> Hi,
>>
>> I would like to push another patchset according to the plan I've sent
>> few days ago
>> (hm, 10 days ago actually).
>> the_plan: http://lists.samba.org/archive/samba-technical/2010-November/074938.html
>>
>> In this edition I've stuck on the case when we replicate a Schema, extended with
>> an classSchema inheritet from another custom Class with added attribute.
>>
>> I've tried to write down more detailed commit messages. Hope this helps.
>
> I'm not sure it's correct to always use a new working schema, while
> replicating
> the schema partition, is the remote and local prefix map match we don't
> need that
> overhead.
>
Actually I introduced working_schema not because of prefixMap issues,
but because of verification issues I had we modules in ldb stack.
The problem is that when replicating Schema, we might have
new schema objects that are interdependent.
Consider the last test I've introduced - we have a new class B, that depends
on new class A and new attribute attrA.
In this case I stuck in linked_attributes.c module - when it gets class A,
it checks all its attributes and it fail, because we don't have attrA in our
local Schema cache.
So, I think we should have a reasonable schema Cache while
applying replicated objects, so that modules in the chain
can do their job as in normal cases

> As far as I understand with your patches it would be possible that
> we endup with a different prefix map than the other DC and I'm
> not sure if that's the right behavior.
>
Yes, correct.

> My guess is that the remote prefix map is always a superset of the local
> prefix map and we should just takeover the remote prefix map as local one.
>
> I guess in that case we wouldn't need an extra working schema at all,
> because the remote prefix map should be everything we need to replicate the
> schema.
>
I've considered this approach too - to merge remote prefixMap in
our local prefixMap before decoding received objects.
So we'll end up with same prefixMap as the one from our
replication partner.

I took the current approach though, because it is the same (in the
prefixMap part) as described in ms-docs. It is more generic as it
ensures we don't have collisions between remote-local prefixMap
indexes.
Frankly, I can't think of situation where this might happen.
But I im in the AD development business just for a little bit more
that a year, while MS are in this business for more than decade,
so I prefer to took their approach for granted at the moment :)

P.S. Ah, I've come to a situation with prefixMap collisions.
If we have two DCs - S4 and WinDC, when we replicate
Schema to the WinDC, windows will make random indexes
for new OIDs. I mean it won't merge our prefixMap, but make
a new one. So when replicate back Schema changes (WinDC
all the sudden became a Schema master), then there is a
good chance we won't be able to merge Win prefixMap into
ours.

-- 
CU,
Kamen