directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny" <elecha...@gmail.com>
Subject Re: A control for enabling/disabling dynamic schema check ?
Date Wed, 22 Aug 2007 21:28:40 GMT
Hi Alex,

this is needed for Studio 1.0 and then for ADS 1.5.1


On 8/22/07, Alex Karasulu <akarasulu@apache.org> 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 <pa@marcelot.net> 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 <pa@marcelot.net > wrote:
> > >
> > >
> > >
> > > On 6/12/07, Alex Karasulu < akarasulu@apache.org> wrote:
> > > >
> > > >
> > > >
> > > > On 6/12/07, Pierre-Arnaud Marcelot < pa@marcelot.net> 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

Mime
View raw message