directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject [ApacheDS][Schema] Uncurbed cascade deletes could be disasterous
Date Fri, 24 Aug 2007 18:41:37 GMT
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

Mime
View raw message