Oh and FYI I know PAM asked for this a long long time ago so sorry I'm the one that slacked off on adding this feature.
Alex On 8/22/07, Alex Karasulu <[EMAIL PROTECTED]> wrote: > > Man this is really late in the game don't you think? > > Alex > > On 8/22/07, Emmanuel Lecharny <[EMAIL PROTECTED] > wrote: > > > > 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 > > > >
