Re: rename across trees: manageDIT?

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

At 11:41 AM 8/17/2005, Pierangelo Masarati wrote:
>Kurt D. Zeilenga wrote:
>
>>entryUUID is likely managable, entryCSN not!   Even on a mangedDIT
>>change, entryCSN must be updated otherwise replication won't work
>>right.
>> 
>well, entryUUID is what I'm interested in.  entryCSN was just for completeness.  My point of view is that manageDIT is something in the direction of violating rules, assuming one knows what's doing (that's why we intend to set as many constraints as possible on manageDIT, don't we?).  

ManageDIT is not intended to allow administrators to do anything
they please.  It's intended to more easily work around some
DIT constraints.  For instance, if the admin wants to add some
attribute whose type is currently marked obsolete (e.g., inactive),
the admin could temporarily mark the schema as active, add
the attribute, then mark the attribute type obsolete again.
The manageDIT operation allows those three operations to be
condensed into one operation, and in doing so, avoid nasties
of having the type temporary active.

Likewise for structualObjectClass.  The admin could delete and
re-add the object to accomplish a change in structural object
class.  ManageDIT allowed condensing the delete+add into a
modify.

LDAP requires the DIT to be in a consistent state after each
update (add, delete, modify, rename).  ManageDIT allows
other constraints to be lifted during the processing of the
operation, but the basic DIT consistency requirement must
still hold.

One can argue that UUID/CSNs should be mucked with as
doing so can create inconsistencies.  I haven't much problem
allowing UUIDs to be updated (as long as we don't find any
(replication or other) issue in allowing this, but obviously
allowing CSN updates would be problematic.  (Directory
applications should be using timestamps not CSNs...
which, BTW, one good reason for DSAs to use CSNs in replication.)

Kurt