Date: Mon, 22 Jun 2020 15:43:30 +1000
From: William Brown <wbrown(a)suse.de>
Subject: [389-devel] Advice on a problem (syncrepl + entryuuid)
To: "389 Directory server developer discussion."
<389-devel(a)lists.fedoraproject.org>
Message-ID: <CEAABAA1-E958-4EA6-8432-B7DF92E4AA2C(a)suse.de>
Content-Type: text/plain; charset=utf-8
Hi all,
I've been a bit stuck on this problem, and I was hoping for some advice or thoughts.
So, part of the migration from openldap, and in general, is that we support entryuuid.
That's all fine. I made a decision to allow entryuuid to diverge from nsuniqueid, as
entryuuid is often a primary key in many databases. So we should be able to bring in
entryuuids' that already exist.
This creates a dilema in syncrepl though. Syncrepl currently uses the nsuniqueid in place
of the entryuuid for sync. It does not appear to be straight forward to change this to use
entryuuid if it exists - when we send a delete, that comes from the retro changelog, and
it stores a delete as a delete with the nsuniqueid. That also means the entry that held
the nsunique in question may no longer exist so we cant reference what the entryuuid was.
So this leads me to a problem of "how to solve it".
I still think allowing entryuuid to diverge from nsuniqueid is the right call. It opens
more scenarioes up to us for migration.
Just fyi, when replicating from 389DS to OpenLDAP, we directly map nsUniqueId to
entryUuid. They're
both UUIDs and both serve the same purpose on their respective servers, so why is there
any reason to allow proliferation of other IDs?
--
-- Howard Chu
CTO, Symas Corp.
http://www.symas.com
Director, Highland Sun
http://highlandsun.com/hyc/
Chief Architect, OpenLDAP
http://www.openldap.org/project/