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 Thu, 23 Aug 2007 13:24:58 GMT
PAM is there a JIRA on this already?  Just looked for it but asking just in
case before I recreate it.

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.

Alex

On 8/22/07, Alex Karasulu <akarasulu@apache.org> 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 <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