Hi,
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 :
public
Cursor<org.apache.directory.shared.ldap.model.cursor.Tuple<K, V>>
cursor( K key ) throws Exception
{
V raw = bt.find( key );
if ( !allowsDuplicates )
{
return new
SingletonCursor<org.apache.directory.shared.ldap.model.cursor.Tuple<K, V>>(
new
org.apache.directory.shared.ldap.model.cursor.Tuple<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
NoDupsCursor...
May be I'm just lost here, or there is a bit of cleaning to do...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
