directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pierre-Arnaud Marcelot">
Subject Re: A control for enabling/disabling dynamic schema check ?
Date Tue, 12 Jun 2007 08:03:40 GMT
Hi Alex,

I think you need to make the server only writable by the current session
> using the
> control to prevent other clients from making inconsistent updates.

 Exactly. That's why I wanted to use a control. To do a "per request"
disabling feature. Schema check will always be activated unless the control
is present in the request.

Also it's a good idea to add parameters into the schema service and the
> configuration
> that could control this.
> Overall it's a good idea to be able to control the server in this fashion
> however it does
> not come without risk.

Yes, I'm really aware of that. That's why a complete schema integrity
checker will be built in the Dynamic Schema Editor, to prevent putting in
the server a wrong schema configuration that could leave it in a unstable

If you can write code to actually push schema into ou=schema
> properly in the order of dependency leaves first then this would be a
> easier task for
> you than writing the control.

I was actually thinking of writing some kind of "Scheduler" to perform
request in a certain order, but it is really really painful.
Let's say for example, a user has entered a wrong OID for an attribute type.
He changes it in the plugin and pushes back the schema configuration in the
server. In order to do that, with schema check activated, the plugin will
need to:
- first, find all nodes (attribute types and object classes) that depend on
this attribute type
- second, remove all these nodes
- third, delete the entry corresponding to the attribute type with the wrong
- forth, insert the new attribute type with the correct OID
- fifth, re-insert the removed nodes

I can't imagine what it will be when there will be dozens of modifications
to commit... :(

This is one of the examples that made me think about having the ability to
deactivate the check on the schema.
If this kind of mechanism could exist, committing the change would be
- first, delete the entry corresponding to the attribute type with the wrong
- second, insert the new attribute type with the correct OID
And we're done...

I was thinking of a control, to be able to choose whether or not disabling
the schema check on a 'per request' basis, but if it easier to implement
using a stored procedure, or modifying a special "configuration" entry
value, it's not a problem for me...
I don't know the inside of the server enough to see what costs more...

P-A M.

View raw message