On 5/21/07, Stefan Zoerner <email@example.com> wrote:
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?
3. Disable "mozilla" (change attribute value).
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 220.127.116.11.4.1.13718.104.22.168 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.