Hi Alex, this is needed for Studio 1.0 and then for ADS 1.5.1
On 8/22/07, Alex Karasulu <[EMAIL PROTECTED]> wrote: > Hey Pierre not ignoring you but processing backlog and trying to finish up > on presentations. Will > return to this one soon. For the time being is this needed before 1.5.1 > release? > > Alex > > > On 8/20/07, Pierre-Arnaud Marcelot <[EMAIL PROTECTED]> wrote: > > Hi Devs, > > > > I'm returning on this subject as the Online Schema Editor is almost > complete. > > > > I still need to figure out how to integrate the plugin with the > Connections Plugin Stefan S. is working on and also how to send the schema > back to the server (which is the subject of this thread). > > > > I was wondering, as you know the core of ADS better than I do, what is the > best solution. > > A control ? A stored procedure ? Another system ? > > If you could help me find out this. ;) > > > > Thanks, > > > > P-A > > > > > > > > On 6/12/07, Pierre-Arnaud Marcelot <[EMAIL PROTECTED] > wrote: > > > > > > > > > > > > On 6/12/07, Alex Karasulu < [EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > On 6/12/07, Pierre-Arnaud Marcelot < [EMAIL PROTECTED]> 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 process seems very great. :D > > > > > > > > > > > > > > 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. > > > > > > > > > If the extended Response (#5) can give us the result of the schema check > (is the schema integrity ok or not), then I can imagine a process where > before updating the schema in the DIT, we store a backup copy of it (the > unmodified working schema) that we can restore if something goes wrong. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > Ok thanks, I'm going to take a look at that. But I fear the situation in > the Dynamic Schema Editor is even more complicated, since we have to deal > with adding new elements, but also updating and deleting ones. Those three > operations could come to a scheduling nightmare... I need to continue > examine the different use-cases... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > OID and names (aliases) are required, since they are used in the > definition of the other elements. > > > > > > > > > > > > > > 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 understand that. I'm also looking for the easiest solution for > everyone, on the server and the client side. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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 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... > > > > > > > > > > > > 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. > > > > > > > > > Sounds great. > > > > > > P-A M. > > > > > > > > > > > > -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
