Hi Stefan, On 5/21/07, Stefan Zoerner <[EMAIL PROTECTED]> 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
