Le 19/10/15 03:24, Howard Chu a écrit : > Emmanuel Lécharny wrote: >> Hi, >> >> some thoughts about the current implementation : >> >> Cursor support in Mavibot >> ------------------------- >> >> The current implementation is a bit unsastifactory, and it does not >> necessarily fits with the simplifications we are introducing (namely, >> the removal of duplicate values). Typically, the current cursor allows >> the user to move forward and backward across keys and values, when we >> only need to move across keys now. >> >> Moving >> ------ >> >> First of all, we must be able to move backward and forward. Fetching an >> element is a different operation than moving, but one should still be >> able to get back an element when moving. This is done through 4 methods, >> 2 which are relative, and 2 which are absolute. >> >> Relative moves : >> next() : move forward to the net key >> prev() : move forward to the net key >> >> Absolute moves : >> next(K) : move after the given key >> prev(K) : move before the given key > > These absolute moves seem like an extravagance. I have never seen a > dbm-style library with such methods. It's more natural to have an > explicit seek() method and then do a relative next/prev after that.
It is used for searches like (age>20). If the key 20 does not exist in the B-tree, next(20) will move to the closest key above 20, and prev(20) will move to the closest key below 20. If the key 20 exists, then next(20) will be moved after the key 20 and prev(20) before the key 20. Now, we may need a seek(K) to fetch an element we know exists in the Btree, to avoid having to do things like prev(K); tuple = next(); I have to thought a bit more about the real need for those before(K) and after(K) methods, wil wait for my morning shower for that : insomnia is not the best timing to have a clear thought about API design decisions ;-) > > For reference, in BerkeleyDB, there is cursor_first/last. Also, on a > freshly created cursor, next() == first() and prev() == last(). That > is, the first/last methods aren't even needed on a fresh cursor. That's probably a better idea than what we currently have... Note than the previous Mavibot implementation was copied from ApacheDS implementation, where we had those beforeFirst()/afterLast(). First and Last are probably better names.
