Max Bolingbroke wrote:

On 2 August 2014 17:43, Howard Chu <hyc@symas.com mailto:hyc@symas.com> wrote:

Max Bolingbroke wrote:

    OK, that does make sense. So MDB_CURRENT is totally useless with
    MDB_DUPSORT?
    Since you are either pointing at the (k, v) pair already (so the put
    will do
    nothing) or you aren't (so the put will break the DB).


The feature would not exist if it were useless.

An alternative explanation for the existence of MDB_CURRENT could be that it is useful without MDB_DUPSORT (which is certainly is!) but is useless with it on. I take it from this remark that you do see some use for the combination of the two options but I guess I must be too stupid to see what that is!

I suppose that MDB_CURRENT might be useful with MDB_DUPSORT if you could use it to replace the (key, value) pair being pointed to by the cursor with a different (key, value) pair, so long as the LMDB user knew that the replacement would not violate the LMDB invariant that duplicates must be sorted and distinct. Though this use case "seems" to work with the current implementation the docs certainly do not promise that this is supported.

What defines a "match" depends on the comparison function. If you use a comparator that only uses a portion of the value then of course you can store different values that still match. Prefix comparison is the most obvious example.

The recent doc changes are a bit over-zealous here. The only requirement is that the new value would naturally sort into the same position. So yes, you can store a value different than the old value.