Hi Alex, PAM is there a JIRA on this already? Just looked for it but asking just in > case before I recreate it.
No, there's no Jira yet. Only this thread. I just reread this thread and will begin working on the feature > immediately. What I will be > doing is adding a cascade request control which can be used with several > request types > like delete and modify. The presence of this control will make the server > manage referential > integrity for you within the schema subsystem. This will mean your code > simply needs > to perform a modify operation on the schema element (with dependenees) > using this > control. This control will only be needed to be used on deletes, and > modify operations (which > change the OID or alias) of schema entries. Do you understand the > repercussions of this? If > you have any questions please ask me. Yes, it's understood. That sound exactly what is needed. Thanks a lot. I wish I could have written this control myself, to let you focus on other important things, but my knowledge of the code of the server is still to light ATM... I searched a bit but without really knowing where to look. I'll examine carefully your commits to be able to write such controls in a near future. Thanks again. P-A Alex > > On 8/22/07, Alex Karasulu <[EMAIL PROTECTED] > wrote: > > > > 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Ã(c)charny > > > > www.iktek.com > > > > > > > > > > > > >
