Re: (ITS#7914) LMDB: MDB_DUPSORT and mdb_cursor_put(.., MDB_CURRENT) can put DB in illegal state

[hyc@symas.com]

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.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/