directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject Re: DIRSERVER-936 & 927 Questions
Date Mon, 21 May 2007 14:14:34 GMT
Hi Stefan,

On 5/21/07, Stefan Zoerner <stefan@labeo.de> wrote:
>
> Hi Emmanuel!
>
> Emmanuel Lecharny wrote:
>
> > Now, here are the questions :
> > 1) If the requested Attribute is described in a disabled schema, what
> > should we do ?
>
> During some thinking and testing w.r.t. to your questions, I faced the
> following: Is it possible to have an entry, which uses an attribute
> types of a disabled schema?


SNIP


> 3. Disable "mozilla" (change attribute value).
>
> dn: cn=mozilla,ou=schema
> m-disabled: TRUE
>
> Please note, that this is possible, although the schema is used by an
> entry. Q: Is this intended?


Yes after disabling a schema you leave the data store with entries using
those disabled schema entities in an inconsistent state.  You can do this
with other LDAP servers as well.  Nothing prevents you from doing so.

4. Entry "cn=Tori Amos,dc=example,dc=com" still exists in the storage,
> but it is not possible to fetch it with a search:
>
> $ ldapsearch -h localhost -p 10389 -D "uid=admin,ou=system" -w secret -b
> "dc=example,dc=com" -s one "(objectClass=*)"
> ldap_search: Alias problem
> ldap_search: additional info: failed on search operation: objectClass w/
> OID 1.3.6.1.4.1.13769.2.2.1 not registered!
> $
>
> This is obviously related to DIRSERVER-936. My question: How to handle
> disabling a schema, if there are still entries which use it? I guess it
> is a very expense operation to check this condition ... Or is it still
> implemented, but the way I disabled the schema was illegal?


I would say this is illegal to do however as you saw it can occur in almost
any
LDAP server.  To stop this from happening the schema subsystem can check to
see if the elements of a schema that is being disabled is in use within
entries
in the data stores of the server.

Now doing so is possible if all partitions are attached to the nexus when
this schema
disabling occurs then the server can do a check to see if every entry is
using any of
the entities in the schema to disable.

With a VLDB (very large data base) this could take a long time especially if
there are
no indices built on the attributes being disabled.  A full index scan can
result when
each attribute for example is being checked to see if it is in use.

An optimization can be performed though where we check first to see if any
objectClass of the schema to be disabled is in use.  For this we have a
default
objectClass index to leverage so it will not result in a full master table
scan.  Next
we can check all entries which implement extensibleObject in case these
entries
are using an attribute without using an objectClass in the schema to be
disabled.
As you can see this as well is involved but luckily we can leverage the
objectClass
index for it.  Even with these optimizations this modify operation on the
m-disabled
attribute of the schema could take a very long time if there are lots of
entries in
the partitions of the server.

Another thing we can do is make this additional check configurable in the
schema
subsystem so if people want it they can use it.  Also another approach is to
use better
tooling to deal with these issues which can check if such conditions will
arise instead
of using server cycles.

Alex

Mime
View raw message