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 (nike.apache.org: domain of elecharny@gmail.com designates
 74.125.78.24 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=sender:message-id:date:from:user-agent:mime-version:to:subject
         :references:in-reply-to:content-type:content-transfer-encoding;
        b=FCtzzF13txL0o0i50E/j34yso6cD6zSJDaYr3leegx8814WHORRTQVyGuKMei9Jfva
         N8CyqNxiqR+muoKy1UzSswZuQUg/7H6zTKCtyQSy8i+ED1EUlm4EM7ONHbG44t/+VH2D
         qK/K1N0RB+p64+C+RR7ycB+QSMY7GD/uo3Wh4=
Sender: Emmanuel Lecharny <elecharny@gmail.com>
Message-ID: <4AAA6927.1050804@nextury.com>
Date: Fri, 11 Sep 2009 17:13:43 +0200
From: Emmanuel Lecharny <elecharny@apache.org>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: Schema refactory status
References: <4AAA4BCF.5030002@nextury.com>
 <a32f6b020909110657s4543eb41ib0715f3f05e55654@mail.gmail.com>
In-Reply-To: <a32f6b020909110657s4543eb41ib0715f3f05e55654@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Alex Karasulu wrote:
> Hi Emmanuel,
>
> On Fri, Sep 11, 2009 at 4:08 PM, Emmanuel Lecharny <elecharny@apache.org>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 some
>> data into a cn=schemaModifications,ou=schema entry. This entry does not
>> exist, and I don't know what it is supposed to contain. This impact a lot of
>> tests as many of them are enabling a schema, which means a modification in
>> the associated entry.
>>
>>
>>     
> cn=schemaModifications is used to track timestamps on the schema I think.
> 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=schemaModifications ldif file in ldap-schema 
resources, 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 
modification is done to update the modifyTimestamp and modifiersName 
operational attributes. In other words, we write the entry twice on 
disk. A waste, IMHO.

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.


-- 
--
cordialement, regards,
Emmanuel L�charny
www.iktek.com
directory.apache.org