Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (herse.apache.org: domain of pajbam@gmail.com designates
 66.249.82.231 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth;
        b=M6j49k21842CL1gnQU+qezZONcNdvb2Eyc6SDhz9UCVc7R9puxjTm0QzpyXEVlji1h2NbhpYVvXFACUeTiLCIbWZ7yQTc3rt3F14Jy5NzvkfUHUeBVYCAxNqOV8MobJzzaq1mNJmoox8IRdwx+rQcz+K9t+NNE8XEL7um8gI1V0=
Message-ID: <98d8c0860706120103p18a14194rf27fe89b8ee0f9a2@mail.gmail.com>
Date: Tue, 12 Jun 2007 10:03:40 +0200
From: "Pierre-Arnaud Marcelot" <pa@marcelot.net>
Sender: pajbam@gmail.com
To: "Apache Directory Developers List" <dev@directory.apache.org>
Subject: Re: A control for enabling/disabling dynamic schema check ?
In-Reply-To: <a32f6b020706120002w78444b1du2b3d02e8f54cbbd9@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_2513_8502416.1181635420614"
References: <98d8c0860706111502k9df4658s1bb38ab22b60d336@mail.gmail.com>
	 <a1b4a6610706111525j77a6b0o6ea96fad22bb8284@mail.gmail.com>
	 <a32f6b020706120002w78444b1du2b3d02e8f54cbbd9@mail.gmail.com>

------=_Part_2513_8502416.1181635420614
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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.

------=_Part_2513_8502416.1181635420614
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi Alex,<br><br><div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I think you need to make the server only writable by the current session using the
<br>control to prevent other clients from making inconsistent updates.</blockquote><div><br>&nbsp;Exactly. That&#39;s why I wanted to use a control. To do a &quot;per request&quot; disabling feature. Schema check will always be activated unless the control is present in the request.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Also it&#39;s a good idea to add parameters into the schema service and the configuration
<br>that could control this. <br><br>Overall it&#39;s a good idea to be able to control the server in this fashion however it does<br>not come without risk. </blockquote><div><br>Yes, I&#39;m really aware of that. That&#39;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.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">If you can write code to actually push schema into ou=schema<br>
properly in the order of dependency leaves first then this would be a easier task for <br>you than writing the control.</blockquote><div><br>I was actually thinking of writing some kind of &quot;Scheduler&quot; to perform request in a certain order, but it is really really painful.
<br>Let&#39;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:
<br>- first, find all nodes (attribute types and object classes) that depend on this attribute type<br>- second, remove all these nodes<br>- third, delete the entry corresponding to the attribute type with the wrong OID<br>
- forth, insert the new attribute type with the correct OID<br>- fifth, re-insert the removed nodes<br><br>I can&#39;t imagine what it will be when there will be dozens of modifications to commit... :(<br><br>This is one of the examples that made me think about having the ability to deactivate the check on the schema.
<br>If this kind of mechanism could exist, committing the change would be easier:<br>- first, delete the entry corresponding to the attribute type with the wrong OID<br>
- second, insert the new attribute type with the correct OID<br>And we&#39;re done...<br></div><br></div>I was thinking of a control, to be able to choose whether or not disabling the schema check on a &#39;per request&#39; basis, but if it easier to implement using a stored procedure, or modifying a special &quot;configuration&quot; entry value, it&#39;s not a problem for me...
<br>I don&#39;t know the inside of the server enough to see what costs more...<br><br>P-A M.<br>

------=_Part_2513_8502416.1181635420614--