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 ayyagarikiran@gmail.com
 designates 209.85.198.230 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=KDSSRA3MsNnvP87PiIewbR0jia3Bpp8djVGNoeZCRSe+SjJWXur3W/aGggSfy527Uz
         CqBajAkDJAT3fz4Vgko7i3dnkhjW9nq73ni37z6azSu/TFaLvNT3XLW9IhpI5j2QS/KU
         dvzamIrNrKgBrxz0bc6byWqeTT08aRXFDMHP8=
Message-ID: <49D473C7.3070203@gmail.com>
Date: Thu, 02 Apr 2009 13:43:59 +0530
From: ayyagarikiran <ayyagarikiran@gmail.com>
User-Agent: Thunderbird 2.0.0.21 (X11/20090318)
MIME-Version: 1.0
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: [ApacheDS][AvlTreeMap] insert() fails to replace old value
References: <a32f6b020904010858y50366f49k668e439d013852c4@mail.gmail.com>
 <49D3B724.1050004@gmail.com> <27096663-8C70-4C4F-8461-5795F1757F9A@yahoo.com>
 <49D44D06.2060104@gmail.com> <D088FFD5-E7ED-48B4-A5CE-7EECCE3E8F80@yahoo.com>
In-Reply-To: <D088FFD5-E7ED-48B4-A5CE-7EECCE3E8F80@yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


David Jencks wrote:
> 
> On Apr 1, 2009, at 10:28 PM, Kiran Ayyagari wrote:
> 
>> This can easily lead to CCE without some extra checks.
> 
> I don't quite see your point of view.  I figured that "put" methods only 
> return a value when they replace a previous value.  If duplicates are 
> allowed, then put will never replace a value and always return null.  If 
> duplicates are not allowed, then there will be 0 (null) or 1 (V) objects 
> to return.
> 
ah, right, I was mixing both the value passed and the actual 'value' present in node.

> I don't see how a return from this can be useful unless something like 
> remove(K, null) removes all the values associated with K.  In that case 
> returning AvlTree<V> might be more appropriate.  On the other hand my 
> naive expectations would be that remove(K, null) would only remove 
> something is insert(K, null) had been called.  If I wanted to remove all 
> the values associated with a K I'd want a method remove(K) and having 
> this return an AvlTree(V) seems more appropriate (this could be a 
> singleton if there is only one value).

the current impl removes the all the values associated with a key if remove(K,null) is called
assuming that we don't allow null to be inserted by checking at a higher level (ex. the XXXTable implementations)

But, yes this is certainly possible to have null values, provided the comparators handle them properly.

Returning a singleton AvlTree<V> would be a overhead, but if this is something really required will add it

thanks David.

Kiran Ayyagari