Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 1700 invoked from network); 30 May 2008 23:24:33 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 30 May 2008 23:24:33 -0000 Received: (qmail 37149 invoked by uid 500); 30 May 2008 23:24:35 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 37099 invoked by uid 500); 30 May 2008 23:24: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 37088 invoked by uid 99); 30 May 2008 23:24:35 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 30 May 2008 16:24:35 -0700 X-ASF-Spam-Status: No, hits=2.0 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.198.236 as permitted sender) Received: from [209.85.198.236] (HELO rv-out-0506.google.com) (209.85.198.236) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 30 May 2008 23:23:48 +0000 Received: by rv-out-0506.google.com with SMTP id g37so1122050rvb.25 for ; Fri, 30 May 2008 16:24:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=773D9f3TGq5Hqxi0cLWAA+ojJbbRG/q8LXqmf9RTUrw=; b=EZbd8CFZ+RFm+u/KvQB0SPvjR+iJXSUhPqQ9tWuuDxmqEmBZWJsas1L+Jm7A6z94JFDzdnt1n2M53Y1w2ohTg3YlPj4CsuE0PQZISZPP2xXubVzLq5cH+1pIxOuF4nXCGUcVl2l1DTghQJE6w4hw1OhIWxf9y2NpPLkukvnq9WQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=NzeoqN6wdiT3+yqGPtL6v/Si5Qb9ZpJw/cRL8QO/DH6xYJaLNodVfuoTdSm+CIk9Zi7yQAmzQXPrVn0VyzISSvPRehUZjt543gn2z5lZvO5O//l87vklFzEQhLrc5MSFmkcp/nqZze1TRHXKT/2lJ4rMgH94i+zeTEKjvXe+YwA= Received: by 10.140.125.1 with SMTP id x1mr3408040rvc.217.1212189845064; Fri, 30 May 2008 16:24:05 -0700 (PDT) Received: by 10.141.113.13 with HTTP; Fri, 30 May 2008 16:24:05 -0700 (PDT) Message-ID: Date: Fri, 30 May 2008 19:24:05 -0400 From: "Alex Karasulu" Sender: akarasulu@gmail.com To: "Apache Directory Developers List" Subject: Re: interface changes in Table and MasterTable In-Reply-To: <48406AE4.4060309@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1197_31813660.1212189845046" References: <48406AE4.4060309@gmail.com> X-Google-Sender-Auth: 92f3492445523f22 X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_1197_31813660.1212189845046 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Fri, May 30, 2008 at 5:00 PM, Kiran Ayyagari wrote: > hi All, > > Below is the summary which lead to the modification of put() and > remove()/delete() method signatures in > Table and MasterTable. > > Changed Interfaces :- The put() and remove() methods in Table and put() and > delete() methods in MasterTable. > > The context :- Implementation of a Berkeley DB JE based partition for ADS. > > Reason for the change :- In the Jdbm based Table implementation put() and > remove() operations return a value > cause JDBM returns the > existing/previous values (like a HashMap) for put and remove > and these values are returned from > the above mentioned operations. > > But JE doesn't return these > (existing/previous) values instead returns a special Enum > value stating the success or > failure of the operation. > > However I have observed that the return values of the existing put() and > remove() methods are not used anywhere hence I made the above said change ( > tested this by changing the interfaces and the respective implementations > and ran all tests ( Note: no functional aspects of the implementations was > touched except removing or replacing the *return* statements) ) > > thoughts? > This sounds good - we certainly don't want to bother with the overhead of an additional lookup. > P.S :- In the JE based implementation we can still return the > previous/existing value but this requires a > lookup in each operation (put and remove) for storing the old value > but this is not a desirable implementation. > Thanks, Alex ------=_Part_1197_31813660.1212189845046 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Fri, May 30, 2008 at 5:00 PM, Kiran Ayyagari <ayyagarikiran@gmail.com> wrote:
hi All,

   Below is the summary which lead to the modification of put() and remove()/delete() method signatures in
   Table and MasterTable.

Changed Interfaces :- The put() and remove() methods in Table and put() and delete() methods in MasterTable.

The context :- Implementation of a Berkeley DB JE based partition for ADS.

Reason for the change :-  In the Jdbm based Table implementation put() and remove() operations return a value
                                         cause JDBM returns the existing/previous values (like a HashMap) for put and remove
                                         and these values are returned from the above mentioned operations.

                                         But JE doesn't return these (existing/previous) values instead returns a special Enum
                                         value stating the success or failure of the operation.

However I have observed that the return values of the existing put() and remove() methods are not used anywhere  hence I made the above said change ( tested this by changing the interfaces and the respective implementations and ran all tests ( Note: no functional aspects of the implementations was touched except removing or replacing the *return* statements) )

thoughts?

This sounds good - we certainly don't want to bother with the overhead of an additional lookup.


P.S :- In the JE based implementation we can still return the previous/existing value but this requires a
       lookup in each operation (put and remove) for storing the old value but this is not  a desirable        implementation.

Thanks,
Alex

------=_Part_1197_31813660.1212189845046--