You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Pierre-Arnaud Marcelot <pa...@marcelot.net> on 2007/06/12 00:02:07 UTC
A control for enabling/disabling dynamic schema check ?
Hi Directory developers,
I'm currently working on the Dynamic Schema Editor for Apache Directory
Server.
I have already managed to get the Schema from the DIT and transform into
Java objects.
I was wondering if we could create a control that can enable or disable the
schema check done by the server when modifying the ou=schema subtree ?
It could be very helpful to be able to disable the schema check to authorize
the dynamic schema editor to reorganize the schema doing multiple
add/delete/modify operations (removing an attribute type even if another
object depends on that one, for example).
Do you think this is possible ?
Thanks,
P-A M.
Re: A control for enabling/disabling dynamic schema check ?
Posted by Alex Karasulu <ak...@apache.org>.
Oh and benefit (7) when put into the server all clients can benefit from
this control
like JNDI clients as opposed to having this capability with just Studio: not
that I
personally would use any other client :-D.
Alex
On 6/12/07, Alex Karasulu <ak...@apache.org> wrote:
>
> Actually come to think of it the use of a cascade req. control along with
> pushing
> the logic into the server close to where the data resides might be the
> best
> approach. It certainly will be faster and safer:
>
> (1) the data is local so access and writes are faster
> (2) the schema subsystem manages it so the code is isolated where it
> belongs
> (3) the failure of the network connection between the client and the
> server will
> not result in leaving the server in an inconsistent state with
> respect to the schema
> (4) the client does not have to deal with latency and multiple operations
> so
> over all the performance will be faster
> (5) the client complexity decreases
> (6) when transactions are enabled with better atomicity and isolation then
> rollbacks
> can be enabled and there is no inconsistent state for the schema
> (regardless
> we can still make sure the schema is not inconsistent while
> performing these
> operations in the server - just more work)
>
> Some drawbacks:
>
> (1) the server's schema subsystem must have code added to it to handle
> this control
> (2) more complexity in the schema subsystem but not as much as in the
> client
> since there are structures already present in the schema subsystem
> for managing
> these kinds of operations/checks
> (3) time :)
>
> Alex
>
> On 6/12/07, Alex Karasulu <ak...@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 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.
> >
> > 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.
> >
> > 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.
> >
> > 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 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.
> >
> > Thoughts?
> >
> > Alex
> >
> >
>
Re: A control for enabling/disabling dynamic schema check ?
Posted by Alex Karasulu <ak...@apache.org>.
Actually come to think of it the use of a cascade req. control along with
pushing
the logic into the server close to where the data resides might be the best
approach. It certainly will be faster and safer:
(1) the data is local so access and writes are faster
(2) the schema subsystem manages it so the code is isolated where it belongs
(3) the failure of the network connection between the client and the server
will
not result in leaving the server in an inconsistent state with respect
to the schema
(4) the client does not have to deal with latency and multiple operations so
over all the performance will be faster
(5) the client complexity decreases
(6) when transactions are enabled with better atomicity and isolation then
rollbacks
can be enabled and there is no inconsistent state for the schema
(regardless
we can still make sure the schema is not inconsistent while performing
these
operations in the server - just more work)
Some drawbacks:
(1) the server's schema subsystem must have code added to it to handle this
control
(2) more complexity in the schema subsystem but not as much as in the client
since there are structures already present in the schema subsystem for
managing
these kinds of operations/checks
(3) time :)
Alex
On 6/12/07, Alex Karasulu <ak...@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 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.
>
> 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.
>
> 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.
>
> 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 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.
>
> Thoughts?
>
> Alex
>
>
Re: A control for enabling/disabling dynamic schema check ?
Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
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 <ak...@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 <ak...@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
> > > >
> > >
> > >
> >
>
Re: A control for enabling/disabling dynamic schema check ?
Posted by Alex Karasulu <ak...@apache.org>.
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 <ak...@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 <ak...@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 <ak...@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
> > >
> >
> >
>
Re: A control for enabling/disabling dynamic schema check ?
Posted by Alex Karasulu <ak...@apache.org>.
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 <ak...@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 <ak...@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
> >
>
>
Re: A control for enabling/disabling dynamic schema check ?
Posted by Alex Karasulu <ak...@apache.org>.
Man this is really late in the game don't you think?
Alex
On 8/22/07, Emmanuel Lecharny <el...@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 <ak...@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
>
Re: A control for enabling/disabling dynamic schema check ?
Posted by Emmanuel Lecharny <el...@gmail.com>.
Hi Alex,
this is needed for Studio 1.0 and then for ADS 1.5.1
On 8/22/07, Alex Karasulu <ak...@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
Re: A control for enabling/disabling dynamic schema check ?
Posted by Alex Karasulu <ak...@apache.org>.
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.1release?
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.
> >
> >
>
Re: A control for enabling/disabling dynamic schema check ?
Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
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 <ak...@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.
>
>
Re: A control for enabling/disabling dynamic schema check ?
Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
On 6/12/07, Alex Karasulu <ak...@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.
Re: A control for enabling/disabling dynamic schema check ?
Posted by Alex Karasulu <ak...@apache.org>.
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 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.
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.
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.
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 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.
Thoughts?
Alex
Re: A control for enabling/disabling dynamic schema check ?
Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
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.
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.
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
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...
P-A M.
Re: A control for enabling/disabling dynamic schema check ?
Posted by Alex Karasulu <ak...@apache.org>.
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.
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. 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. However we could support this but it will not
be a simple
matter.
Alex
On 6/12/07, Ersin Er <er...@gmail.com> wrote:
>
> Hi PAM,
>
> It can be possible by disabling the Schema Service at runtime. This
> can be done by a stored procedure or by a special entry which tracks a
> special value for schema enabling/disabling. But I am not sure about
> its side effects.
>
> On 6/12/07, Pierre-Arnaud Marcelot <pa...@marcelot.net> wrote:
> > Hi Directory developers,
> >
> > I'm currently working on the Dynamic Schema Editor for Apache Directory
> > Server.
> > I have already managed to get the Schema from the DIT and transform into
> > Java objects.
> > I was wondering if we could create a control that can enable or disable
> the
> > schema check done by the server when modifying the ou=schema subtree ?
> >
> > It could be very helpful to be able to disable the schema check to
> authorize
> > the dynamic schema editor to reorganize the schema doing multiple
> > add/delete/modify operations (removing an attribute type even if another
> > object depends on that one, for example).
> >
> > Do you think this is possible ?
> >
> > Thanks,
> >
> > P-A M.
> >
>
>
> --
> Ersin Er
>
> R.A. and Ph.D Student at the Dept. of Computer Eng. in Hacettepe
> University
> http://www.cs.hacettepe.edu.tr
>
> Committer and PMC Member of The Apache Directory Project
> http://directory.apache.org
>
Re: A control for enabling/disabling dynamic schema check ?
Posted by Ersin Er <er...@gmail.com>.
Hi PAM,
It can be possible by disabling the Schema Service at runtime. This
can be done by a stored procedure or by a special entry which tracks a
special value for schema enabling/disabling. But I am not sure about
its side effects.
On 6/12/07, Pierre-Arnaud Marcelot <pa...@marcelot.net> wrote:
> Hi Directory developers,
>
> I'm currently working on the Dynamic Schema Editor for Apache Directory
> Server.
> I have already managed to get the Schema from the DIT and transform into
> Java objects.
> I was wondering if we could create a control that can enable or disable the
> schema check done by the server when modifying the ou=schema subtree ?
>
> It could be very helpful to be able to disable the schema check to authorize
> the dynamic schema editor to reorganize the schema doing multiple
> add/delete/modify operations (removing an attribute type even if another
> object depends on that one, for example).
>
> Do you think this is possible ?
>
> Thanks,
>
> P-A M.
>
--
Ersin Er
R.A. and Ph.D Student at the Dept. of Computer Eng. in Hacettepe University
http://www.cs.hacettepe.edu.tr
Committer and PMC Member of The Apache Directory Project
http://directory.apache.org