Thank you so much for your comments and suggestions, Andrey! Some look
easy (e.g., the first item -- I'm turning it on and run more tests), and
some look more challenging. I'm going to make a ToDo section in the
wiki page and add your list to the section.
Andrey Ivanov wrote:
I've seen some changes in the USN design document, so i'll
add my two
cents. Overall it's well written, the architecture seems to be rather
robust. There are some scenarious that are interesting for us as for
the behaviour of the usn plugin and some questions/reflections :
* The USNs seem to be unique within a suffix/backend. Should we enable
the uniqueness plug-in for them? If not can we be sure that a manual
change of entryUSN will not interfere with the correct functioning of
* When the plug-in is activated no entry has entryUSN or maybe some
entries do already have it in some desorder. Maybe we should
initialise (while plug-in in started for the VERY first time) all the
entries without entryUSN with entryUSN=-1 or smth like that?
* Maybe it's a good idea to desactivate the replication of entryUSN
attribute during the server installation by default?
* When we do an export with a utility like db2ldif.pl - should the
entryUSN attributes be exported or not?
* What happens during the import of a whole ldif subtree by smth like
"ldif2db -n userRoot -i /tmp/current_prod_database.ldif" if the
entryUSNs are already present in the imported ldif? If they are not
present? if they are present only in a part of the entries?
* Should usn-tombstone-cleanup be integrated in the server core with
the thread purging the tombstones ot not? Should it be configurable bo
some attributes like nsds5ReplicaPurgeDelay and
And thank you for your work!
389-devel mailing list