[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: entryUUID

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 somehow programmatically).

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.

p.


   SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497