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
