directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <>
Subject Re: Question about JDBM key/value replacement
Date Fri, 27 Apr 2012 13:06:35 GMT
Le 4/27/12 2:09 PM, Selcuk AYA a écrit :
> Hi,
> On Thu, Apr 26, 2012 at 4:52 PM, Emmanuel Lécharny<>  wrote:
>> Hi guys,
>> currently, we can replace an existing value when its associated key exists
>> in the BTree. What I'd like to do is to replace both key and value in this
>> case.
>> The rational is that the key mau contain some extra information that are not
>> used to find the key, like the nbChildren/nbDescendant for a ParentIdAndrdn
>> key in the RdnIndex.
>> Is there an easy way to do that with JDBM, or should we extend the API it
>> offers ?
> as I understand you are trying to store some auxiliary information per
> key?

>   With JDBM we can:
>    - provide<K, aux>  tuple as the key and pass the key comparator to
> be the comparator for the actual keys.
>    - change JDBM code to update key inside when replacing an entry.
> however, in general, I do not think we can expect a key/value store to
> update the key when replacing an entry. So I am not sure it is a good
> idea to do this kind of thing.

The pb is that those auxiliary informations are not part of the compare 
being done. Ie, two keys may be seen as equals, but the auxiliary 
information might be different. In this very case, I'd like the new 
version of the key replaced.
It may be very specific to my need, and we can also consider that the 
value might cary those extra informations, too, instead of storing them 
in the key.

So for the <ParentIdAndRdn, ID> tuple, where the data structure is :
ParentIdAndRdn :
     ID parentId,
     Rdn[] rdns,
     int nbChildren,
     int nbDescendant

we could inject the two ints after having read the value if this value 
structure was :

     ID id
     int nbChildren,
     int nbDescendant

and serializing the ParentIdAndRdn ID and Rdn[] only.

That may work...

thoughts ?

Emmanuel Lécharny

View raw message