directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pierre-Arnaud Marcelot" ...@marcelot.net>
Subject Re: A control for enabling/disabling dynamic schema check ?
Date Thu, 23 Aug 2007 14:19:02 GMT
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 <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Ã(c)charny
> > > > www.iktek.com
> > > >
> > >
> > >
> >
>

Mime
View raw message