Re: svn commit: r1330754 [1/3] - in /directory/apacheds/branches/index-work: core-constants/src/main/java/org/apache/directory/server/constants/ jdbm-partition/src/test/java/org/apache/directory/server/core/partition/impl/btree/jdbm/ ldif-partition/s

[Alex Karasulu <ak...@apache.org>]

On Thu, Apr 26, 2012 at 1:22 PM, <el...@apache.org> wrote:

> Author: elecharny
> Date: Thu Apr 26 10:22:13 2012
> New Revision: 1330754
>
> URL: http://svn.apache.org/viewvc?rev=1330754&view=rev
>


> o Changed the IndexEntry interface to reflect the nature of the stored
> elements : namely, a key and an ID. The getValue/setValue have been renamed
> getKey/setKey
>
>
There was a big reason why this was getValue/setValue as opposed to
getKey/setKey. You sure this was a good decision to change this?

I must admit I don't immediately remember what that reason was but I too
wanted to change it to getKey/setKey but I resisted that when I had more
information available to me. At this point I don't remember it fully but
know it happens to do with directionality when using reverse or direct
btrees in the index.

Regards,
Alex

Re: svn commit: r1330754 [1/3] - in /directory/apacheds/branches/index-work: core-constants/src/main/java/org/apache/directory/server/constants/ jdbm-partition/src/test/java/org/apache/directory/server/core/partition/impl/btree/jdbm/ ldif-partition/s

[Emmanuel Lécharny <el...@gmail.com>]

Le 4/26/12 2:33 PM, Alex Karasulu a écrit :
> On Thu, Apr 26, 2012 at 1:22 PM,<el...@apache.org>  wrote:
>
>> Author: elecharny
>> Date: Thu Apr 26 10:22:13 2012
>> New Revision: 1330754
>>
>> URL: http://svn.apache.org/viewvc?rev=1330754&view=rev
>>
>
>> o Changed the IndexEntry interface to reflect the nature of the stored
>> elements : namely, a key and an ID. The getValue/setValue have been renamed
>> getKey/setKey
>>
>>
> There was a big reason why this was getValue/setValue as opposed to
> getKey/setKey. You sure this was a good decision to change this?

Let me explain why I did such a change...

At some point, reading the Javadoc, such a change was making sense to 
me, and I was a bit lost in the value/key meaning (see below) :

IndexEntry<V, ID>

/**
  * Interface for index entries. An index entry associate an Entry with
  * a value (the key) and the Entry ID in the table where it's stored. 
The Entry...
    ^^^^^^^^^^^^^

The so called value is the key to get the entryID.

>
> I must admit I don't immediately remember what that reason was but I too
> wanted to change it to getKey/setKey but I resisted that when I had more
> information available to me. At this point I don't remember it fully but
> know it happens to do with directionality when using reverse or direct
> btrees in the index.
We have two classes implementing this interface :
- ForwardIndexEntry
- ReverseIndexEntry

They both extends an AbstractIndexEntry, which in fact is only used by 
the ForwardIndexEntry (all the other shared methods are abstract). 
Moreover, when you check the getValue() and setValue() methods, you have :

ForwardIndexEntry.getValue()
     {
         return tuple.getKey();
     }

ReverseIndexEntry.getValue()
     {
         return tuple.getValue();
     }

which is quite confusing, IMO... I'm wondering if it would not be better 
to redefine the interface to just expose the tuple, and nothing else, 
assuming that the tuple is declared as Tuple<V, ID> in the 
ForwardIndexEntry and Tuple<ID, V> in the ReverseIndexEntry...

So if you remember the exact reason why we use getValue()/setValue() 
instead of getKey()/setKey(), it would help me a lot !


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com