Hi all, I've been working on implementing this cascading control in the context of the schema subsystem which is highly specialized with cross references and dependencies to model inheritance of attributeTypes and objectClasses. This is why a cascade option is needed while performing modify operations. I am realizing that there are some limitations to doing this properly and at the same time there are serious pitfalls in this feature without it being curbed.
I don't think we should add this feature without having the ability to mark schemas, and individual schema elements as read-only (exposed in subschemaSubentry as X-READ-ONLY schema extension). Only the administrator and owner of the schema should have the ability to revert the read only flag. Even the admin should not be able to delete schema elements with or without the cascade control present if any element in the dependency chain is marked read only. Now here is my dilema. I would never allow a production grade release without having these checks in place. Just imagine what would happen if the admin deleted the 'top' objectClass or the 'name' attributeType: a large amount of the schema would be blown away and the server would be rendered useless although blowing away the schema partition folder will recreate it with the defaults. Regardless should we allow this feature in this (non-production) feature release with a warning. Another option is to disable cascade deletes for now and just support cascading modifications? Thoughts? Alex
