[Date Prev][Date Next]
Kurt D. Zeilenga wrote:
A change of subject seems in order...
My initial concern with moving entryUUID generation out of
the frontend was that it might make implementation of manageDIT
capabilities a bit harder.
Another concern would be to ensure that UUIDs generated for
entries are "reasonably unique".... and, for that, I have some
concerns with the use of uuid_create_from_name(). What were
you thinking of using as a name? Is it "reasonable unique"?
In principle, whatever. DN at worst, but many vendors provide unique
attrs in their DSAs, and many deployments keep reasonably unique
counters in their data.
I want to use syncrepl to easily build a "master" consumer out of third
party DSAs that don't support all stuff required by syncrepl, the first
of all the control itself, but also the structuralObjectClass (which I
plan to compute out of the objectClass chain), the entryCSN (which I
plan to estimate from a timestamp whatever, or just to set to something
higher than the current CSN, at worst, like it's currently done in
back-sql), but I need to be able to generate repeatable entryUUIDs (the
"reasonably unique" is essentially intended within a context, and it's
an issue I'll need to think about; unless I can do something "absolutely
unique" and two-way like in back-sql using tables and rows ids, I need a
general way to use the DN, at least one-way; the other can be done
Currently, as a testbed, I'm using OpenLDAP 2.1 as provider, so none of
the above is available and I need to be able to create all of them.
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497