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:20:02 GMT
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 <akarasulu@apache.org> wrote:
>
> 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