directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject Re: A control for enabling/disabling dynamic schema check ?
Date Wed, 22 Aug 2007 22:19:10 GMT
Man this is really late in the game don't you think?

Alex

On 8/22/07, Emmanuel Lecharny <elecharny@gmail.com> wrote:
>
> 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