directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny" <>
Subject Re: [ApacheDS][Schema] Uncurbed cascade deletes could be disasterous
Date Sat, 25 Aug 2007 07:27:30 GMT
Hi Alex,

this is a complex issue, and we won't have easy solution.

First point, we have to stress the fact that this is not a 'stable'
version, or as we discussed it a few months ago, this is an
intermediate version. So implementing a partial solution is not really
a problem.

This being said, here are some thoughts, comments inline :

> 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.

The main problem is that we have no idea about the potential impact of
a schema modification before we see its real impact on an existing
base. Now, we also must assume that the admin 'knows' what he is doing
(this is a wish ;). I have read a discussion about the removal of the
m-oid attribute and its consequences. I felt like it was pretty much a
discussion about what will happen to someone who play russian roulet
with 6 bullets in the gun... Brain damages will be at least severe,
but there is no way to fix the gun to avoid such damages !

Ok, I agree that the meta-schema should _not_ be writable. And I also
agree that the core schemas should _not_ be writable either. So let's
use this feature quickly.

> 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.

The admin who delete the 'top' objectClass should be punished for his
sins ! Ok, seriously, there are some objects which need to be
protected. We may add a dsaOperation attribute in such objects to
protect them against destruction. And we can also create a control if
we _really_ need to destroy those objects for some reason (a
combinaison of a delete operation and this specific control will allow
the desctruction). wdyt ?

> Another option is to disable cascade deletes for now and just support
> cascading modifications?

I would suggest that we allow deletes and modifications first, and
restrict them later. It would be so good if we have a way to keep an
history for the schema (a kind of svn repo inside the server), and
allow the admin to revert his changes back to a stable version ! I
guess this could be possible, but I don't know how much it could cost
to implement such a feature !

Emmanuel L├ęcharny

View raw message