[PATCH] Schema replication

[Kamen Mazdrashki]

Hi Metze,

I just wonder wheather my explanations address yuor concerns :)
You can find an updated (rebased) branch at:
http://git.samba.org/?p=kamenim/samba.git;a=shortlog;h=refs/heads/pfm-remote-build

CU,
Kamen

On Fri, Dec 10, 2010 at 13:45, Kamen Mazdrashki <kamenim at samba.org> wrote:
> 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
>