Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 11809 invoked from network); 7 Nov 2006 05:20:04 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 7 Nov 2006 05:20:04 -0000 Received: (qmail 91821 invoked by uid 500); 7 Nov 2006 05:20:15 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 91760 invoked by uid 500); 7 Nov 2006 05:20:15 -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 91749 invoked by uid 99); 7 Nov 2006 05:20:15 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 06 Nov 2006 21:20:15 -0800 X-ASF-Spam-Status: No, hits=2.3 required=10.0 tests=HTML_MESSAGE,MAILTO_TO_SPAM_ADDR,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of trustin@gmail.com designates 64.233.162.203 as permitted sender) Received: from [64.233.162.203] (HELO nz-out-0102.google.com) (64.233.162.203) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 06 Nov 2006 21:20:01 -0800 Received: by nz-out-0102.google.com with SMTP id z3so1030269nzf for ; Mon, 06 Nov 2006 21:19:40 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=tO3LtSY6ShX5yZcNz6WpmJOVzt5NwJrXVmu4k7xOkWES20zMR1rBRhXMG6ClqnXTT16YbfSayJdvcjPbUFwFIDyafZkPdIdLtjg39b0biS9CKbhlHp7T4T++nbXKb1rOfDSRQIooOe+FaS/c9Zv1yyps4MgQqaVJl/5N7Y+XZBM= Received: by 10.35.93.1 with SMTP id v1mr12156321pyl.1162876780069; Mon, 06 Nov 2006 21:19:40 -0800 (PST) Received: by 10.35.68.13 with HTTP; Mon, 6 Nov 2006 21:19:39 -0800 (PST) Message-ID: <768dcb2e0611062119p4ed62031i812c50280dc8f343@mail.gmail.com> Date: Tue, 7 Nov 2006 14:19:39 +0900 From: "Trustin Lee" To: "Apache Directory Developers List" Subject: Re: [Mitosis] IM Session with Trustin In-Reply-To: <455003AB.7050802@bellsouth.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_877_31935250.1162876779950" References: <455003AB.7050802@bellsouth.net> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_877_31935250.1162876779950 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 11/7/06, Alex Karasulu wrote: > > 1). When adding an entry that was already marked entryDeleted true, why > does mitosis perform a modify operation on the entry instead? > > Answer: I don't remember maybe I did it this way because of a lack of > knowledge. No, it was to avoid recursive deletion. 5). Looks like you have not finished implementing the move operation as > is indicated > here in OperationFactory line 188 in newMove(): > > if ( !deleteOldRn ) > { > throw new OperationNotSupportedException( "deleteOldRn must > be true." ); > } > > Is it that you did not implement this or that it was not possible > because of some issue? If deleteOldRn is false, the move operation is not a move operation but a copy operation. This means a newly copied entries have to have different UUIDs. 8). Could you also elaborate more on the log and how it is used? > > Answer: Yep The answer was that logs are used to send the changes made in a replica. The logs are selected and sent to the other replica when UV differences are detected. We also calculate PV and UV from the logs. It's implemented with Derby, an embedded RDBMS, so I used SELECT MAX(...) and MIN(...) to get UV and PV. I think this is already described in the existing documentation. Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP key fingerprints: * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6 ------=_Part_877_31935250.1162876779950 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 11/7/06, Alex Karasulu <aok123@bellsouth.net> wrote:
1). When adding an entry that was already marked entryDeleted true, why
does mitosis perform a modify operation on the entry instead?

Answer: I don't remember maybe I did it this way because of a lack of
knowledge.

No, it was to avoid recursive deletion.

5). Looks like you have not finished implementing the move operation as
is indicated
here in OperationFactory line 188 in newMove():

         if ( !deleteOldRn )
         {
             throw new OperationNotSupportedException( "deleteOldRn must
be true." );
         }

Is it that you did not implement this or that it was not possible
because of some issue?

If deleteOldRn is false, the move operation is not a move operation but a copy operation.  This means a newly copied entries have to have different UUIDs. 

8). Could you also elaborate more on the log and how it is used?

Answer: Yep

The answer was that logs are used to send the changes made in a replica.  The logs are selected and sent to the other replica when UV differences are detected.  We also calculate PV and UV from the logs.  It's implemented with Derby, an embedded RDBMS, so I used SELECT MAX(...) and MIN(...) to get UV and PV.  I think this is already described in the existing documentation.

Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41  4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4  455E 1C62 A7DC 0255 ECA6 ------=_Part_877_31935250.1162876779950--