From dev-return-31341-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Sun Sep 13 07:07:36 2009 Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 26474 invoked from network); 13 Sep 2009 07:07:35 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 13 Sep 2009 07:07:35 -0000 Received: (qmail 16031 invoked by uid 500); 13 Sep 2009 07:07:35 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 15946 invoked by uid 500); 13 Sep 2009 07:07:35 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 15938 invoked by uid 99); 13 Sep 2009 07:07:35 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 13 Sep 2009 07:07:35 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of akarasulu@gmail.com designates 209.85.211.196 as permitted sender) Received: from [209.85.211.196] (HELO mail-yw0-f196.google.com) (209.85.211.196) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 13 Sep 2009 07:07:25 +0000 Received: by ywh34 with SMTP id 34so3475339ywh.10 for ; Sun, 13 Sep 2009 00:07:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=9LylJeCrX4zOD9Ze7mQDpsUISGxyP15hVfNLlm56dnI=; b=ML2mwK/hI+2kDklFgoz1bsN3hcE1vF3+YebgnKJZ0AdLmQSS1kFhbnWf8is6Obg+J0 Lt3cvEm07Pwsf1xGgwJeplR4RoOWov89cBYQZkCo2vlFU9Bz/NcbJk3vYhHnYMn21Noj iJARGWdpwl7rbE7pCnDgj5A+Tn+kfyCwOPSk0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=Cfx3yQy7vw7StM9Mjkl4fQZkTQYfmv49+GzL7WDYl4OZ/i1laRF4a0GGU63GPtzZH9 x/X5WMHoe1asWAhsg3ErLG2vSbFi7VeTfDphyLKvjyBFc6TYHJ62dBhLIFu+4S9uc9f7 vcQsmqL21H3lPIVmTJVc0/I1JRgBKYqiwryBI= MIME-Version: 1.0 Received: by 10.101.165.2 with SMTP id s2mr5323785ano.16.1252825624275; Sun, 13 Sep 2009 00:07:04 -0700 (PDT) In-Reply-To: <4AAA6927.1050804@nextury.com> References: <4AAA4BCF.5030002@nextury.com> <4AAA6927.1050804@nextury.com> Date: Sun, 13 Sep 2009 10:07:04 +0300 Message-ID: Subject: Re: Schema refactory status From: Alex Karasulu To: Apache Directory Developers List Content-Type: multipart/alternative; boundary=0050450146674cebc70473703256 X-Virus-Checked: Checked by ClamAV on apache.org --0050450146674cebc70473703256 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Sep 11, 2009 at 6:13 PM, Emmanuel Lecharny wr= ote: > Alex Karasulu wrote: > >> Hi Emmanuel, >> >> On Fri, Sep 11, 2009 at 4:08 PM, Emmanuel Lecharny > >wrote: >> >> >> >>> Hi, >>> >>> core-integ tests are being fixed slowly but surely. As of today, 164 >>> tests >>> are failing, out of 399. >>> >>> I still have some issues on modifications as we are trying to update so= me >>> data into a cn=3DschemaModifications,ou=3Dschema entry. This entry does= not >>> exist, and I don't know what it is supposed to contain. This impact a l= ot >>> of >>> tests as many of them are enabling a schema, which means a modification >>> in >>> the associated entry. >>> >>> >>> >>> >> cn=3DschemaModifications is used to track timestamps on the schema I thi= nk. >> I'll have to look at it again though. Leave this to me this weekend, I >> think I can scrub it clean. >> >> > > I have added the ou=3DschemaModifications ldif file in ldap-schema resour= ces, > but it's not enough. The RegistrySynchronizerAdaptor class needs to be fi= xed > in order to update this entry when a schema element is modified. > > Make me think that when we have updated the schema on disk, a second > modification is done to update the modifyTimestamp and modifiersName > operational attributes. In other words, we write the entry twice on disk.= A > waste, IMHO. > > Yes we need to fix this. However this problem is not only a schema issue. It happens every time we change an entry period. This is definitely something to consider for optimization. > We should inject those Operational attribute in the list of modifications > and apply them directly. That will have a direct impact on the > OperationalAttribute interceptor. > > Yes I agree however at the time we had some issue that prevented us from doing this. However this may have changed. We need to revisit all the write operations and optimize them. > > > -- > -- > cordialement, regards, > Emmanuel L=E9charny > www.iktek.com > directory.apache.org > > > --=20 Alex Karasulu My Blog :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org --0050450146674cebc70473703256 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Sep 11, 2009 at 6:13 PM, Emmanue= l Lecharny <el= echarny@apache.org> wrote:
Alex Karasulu wrote:
Hi Emmanuel,

On Fri, Sep 11, 2009 at 4:08 PM, Emmanuel Lecharny <elecharny@apache.org>wrote:
=A0
Hi,

core-integ tests are being fixed slowly but surely. As of today, 164 tests<= br> are failing, out of 399.

I still have some issues on modifications as we are trying to update some data into a cn=3DschemaModifications,ou=3Dschema entry. This entry does not=
exist, and I don't know what it is supposed to contain. This impact a l= ot of
tests as many of them are enabling a schema, which means a modification in<= br> the associated entry.


=A0 =A0
cn=3DschemaModifications is used to track timestamps on the schema I think.=
I'll have to look at it again though. =A0Leave this to me this weekend,= I
think I can scrub it clean.
=A0

I have added the ou=3DschemaModifications ldif file in ldap-schema resource= s, but it's not enough. The RegistrySynchronizerAdaptor class needs to = be fixed in order to update this entry when a schema element is modified.
Make me think that when we have updated the schema on disk, a second modifi= cation is done to update the modifyTimestamp and modifiersName operational = attributes. In other words, we write the entry twice on disk. A waste, IMHO= .


Yes we need to fix this.=A0 However this problem = is not only a schema issue.=A0 It happens every time we change an entry per= iod.=A0 This is definitely something to consider for optimization.
=A0
We should inject those Operational attribute in the list of modifications a= nd apply them directly. That will have a direct impact on the OperationalAt= tribute interceptor.


Yes I agree however at the time we had some issue that prevented u= s from doing this.=A0 However this may have changed.=A0 We need to revisit = all the write operations and optimize them.
=A0


--
--
cordialement, regards,
Emmanuel L=E9charny
www.iktek.com
directory.apache.= org





--
Alex Karasu= lu
My Blog :: http://www.j= roller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org

--0050450146674cebc70473703256--