Actually come to think of it the use of a cascade req. control along with pushing
the logic into the server close to where the data resides might be the best
approach. It certainly will be faster and safer:
(1) the data is local so access and writes are faster
(2) the schema subsystem manages it so the code is isolated where it belongs
(3) the failure of the network connection between the client and the server will
not result in leaving the server in an inconsistent state with respect to the schema
(4) the client does not have to deal with latency and multiple operations so
over all the performance will be faster
(5) the client complexity decreases
(6) when transactions are enabled with better atomicity and isolation then rollbacks
can be enabled and there is no inconsistent state for the schema (regardless
we can still make sure the schema is not inconsistent while performing these
operations in the server - just more work)
(1) the server's schema subsystem must have code added to it to handle this control
(2) more complexity in the schema subsystem but not as much as in the client
since there are structures already present in the schema subsystem for managing
these kinds of operations/checks
(3) time :)
On 6/12/07, Pierre-Arnaud Marcelot < email@example.com> wrote: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.
Actually I don't think you can use a control and I want to clarify the required
behavior. First off you need to use an extended request to frame multiple
add requests. It's not so much a control since you have to perform multiple
adds while having the schema checking disabled. See if any schema check
were to occur before the set of operations are completed the schema subsystem
will be in an inconsistent state. Hence no write operations can occur by any
other client session during that frame. Here's what it would look like:
1). Send Disable Schema Checks Extended Request
2). Receive Extended Response (yes or no)
- if yes we can begin and all other client sessions cannot do add/modify/modifyDN ops
- if no then we cannot begin: scheme checking has not been disabled and process ends
3). Sequence of N Add Request/Response Pairs w/ Schema Disabled
4). Send Enable Schema Checks Extended Request
5). Receive Extended Response
So we cannot use a control for this because a series of add requests are required. But
and extended operation is ideal. This btw is how LDAP transactions and other bulk
operation framing mechanisms in some draft specifications work.
The danger of this is that the schema could be inconsistent and you don't have rollback
capabilities since we don't have transactions. I wish we had transaction support since
this is an ideal use case for it.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 state.
I see but would it not just be easier to construct a dependency graph and do a depth
first traversal that adds leaf nodes without dependencies first then working your way
up the dependency tree. This would prevent the need to have to implement such a
complex feature. I'm fine with implementing the feature but it's going to take more
effort than using this client side tactic. There is some code similar to this in the
maven plugin which loads the pre-fabricated schema partition during the build.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 OID
- forth, insert the new attribute type with the correct OID
- fifth, re-insert the removed nodes
Yes I see this is really painful. :(. You basically need to rebuild all the schema objects
that depend on the schema entity you're changing.
What about adding the functionality to the schema subsystem to rename an object and
update the dependent entities that refer to it? This would solve this particular problem
which I think is the biggest one of all. Other use cases like making a change to the
characteristics of the AT or the OC besides the OID can be made without having to take
these painful measures.
I'm trying to find alternatives for this because this schema disabling functionality and it's
impact to the server will not be trivial. Perhaps this will be much harder to implement
then to build a smart rename function into the schema subsystem.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 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 easier:
- first, delete the entry corresponding to the attribute type with the wrong OID
- second, insert the new attribute type with the correct OID
And we're done...
I don't know the inside of the server enough to see what costs more...
Yeah you're onto something with the use of a stored procedure. Perhaps we
can combine some tactics. Just thinking out loud here but we can have a
cascade modify control. Say you rename the OID or alias of a schema entity
and you want the schema system to recursively update the dependencies
like a cascade operation. The schema subsystem can take this into account.
We can even use this control in multiple places. Like for example to do cascade
deletes of schema elements.