Re: backend requirements for syncrepl

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

For UUID, just take something (anything) unique to the
entry, hash it, and stuff it into entryUUID.
For CSN, you can construct something from any timestamp.

Point here is, the actual value of these attributes doesn't
matter, on that the values adhere to the types' semantics.

At 09:01 AM 10/2/2004, Pierangelo Masarati wrote:
>It appears to me (please correct me if didn't get it right) that currently, to be able to support syncrepl, a backend needs to honor the entryUUID and entryCSN operational attributes.  Both of them can be generated by slapd (via the appropriate lutil functions).  The latter, entryCSN, for syncrepl to work correctly can even be generated on the fly, resulting, at worst, in unnecessary overhead in the consumer because entries that are already up to date would appear out of sync. On the contrary, the former, entryUUID, must be preserved across synchronization sessions.  For those backends that do not allow to store this information, entryUUID is likely to be an issue.  I'm thinking about back-sql, of course, but the same considerations may apply to other backend types, like back-perl, back-shell and so, if syncrepl is to be used without being intrusive into the actual storage (if any!). For this purpose, I'm considering the possibility to implement an in-memory, or even on-disk cache that maps DN to entryUUID (although defeating the purpose of UUIDs, in some sense!).  Comments?  Am I overlooking anything?  Is there a possibility that any of the above is not, or may not be in a near future, strictly required by syncrepl?
>
>p.
>
>
>
>   SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497