directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel L├ęcharny <>
Subject [index] Is the SingletonCursor useful ?
Date Thu, 29 Mar 2012 07:39:55 GMT

as I'm trying to go deeper into the Cursor hierarchy (which is quite 
crazy, I must say, with 6 interfaces, 3 abstract classes and 38 
implementations...), I found that we are creating a singletonCursor when 
the underlying table does not allow duplicate values to be stored.

For instance, on JdbmTable, we have such code :

Cursor<<K, V>> 
cursor( K key ) throws Exception
         V raw = bt.find( key );

         if ( !allowsDuplicates )
             return new 
SingletonCursor<<K, V>>(
                 new<K, V>( key, ( V ) 
raw ) );

Why do we have such a cursor ? If we were using a normal cursor, anyway, 
the previous() and next() method will just move out of the possible 
array of values anyway, so the behaviour will be no different, right ?

Also I wonder why there is another method called cursor() which returns 
a browsable cursor over the keys, when the previous cursor is just 
creating a browsable cursor over the values. That's really confusing, 
from the user perspective... It would be way easier if we can disconnect 
the two kind of cursors : the class should return a key cursor, and a 
get() on it will return the values, which will be another cursor (a 
value cursor).

Here, we get the false feeling that calling cursor(K) returns a cursor 
with an initial position set on the K key. Of course, it's also possible 
to do the same thing by calling cursor().beforeKey(K), except that the 
returned DupsCursor/NoDupsCursor we get with the call to Cursor will 
*not* positionning the cursor on the given key, if we have got back a 

May be I'm just lost here, or there is a bit of cleaning to do...

Emmanuel L├ęcharny

View raw message