Re: (ITS#8412) mdb_cursor_del followed by MDB_NEXT_DUP leads to unexpected behaviour

[hyc@symas.com]

lukaswhl@gmail.com wrote:
> Full_Name: Lukas W
> Version: mdb.master 37081325f7356587c5e6ce4c1f36c3b303fa718c
> OS: Linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (2407:7000:9a07:8600::2)
>
>
> The current behaviour of MDB_NEXT_DUP after a mdb_cursor_del call is
> inconsistent with those of other OPs. For instance, MDB_NEXT does not change the
> cursor's position, as this was already done by mdb_cursor_del. As far as I
> understand, mdb_cursor_get can be expected to behave just like usual, whether
> mdb_cursor_get was preceded by a mdb_cursor_del call or not. This saves extra
> checks when e.g. removing particular items in a loop based on some criterion (as
> described and discussed in
> http://www.openldap.org/lists/openldap-devel/201502/msg00027.html and
> follow-ups).
>
> However, this does not apply to MDB_NEXT_DUP. Consider a DB containing the
> following three items:
>
> #1: "a" --> 1
> #2: "b" --> 1
> #3: 2b2b" --> 2
>
> Let's say we have a cursor that points to #1. After calling mdb_cursor_del, #1
> is removed and the cursor points to #2 (though this is not documented anywhere).
> We then call mdb_cursor_get with MDB_NEXT_DUP. We'd expect this call to return
> MDB_NOTFOUND, as #1 was the last item with "a" as its key. This is also what it
> would return if mdb_cursor_del was not called. But in fact, MDB_SUCCESS is
> returned, making anyone who's unaware of this behaviour believe that there's
> another item with the key "a". In my particular case, this leads to #2 being
> deleted as well, even though I only expected to touch items with the key "a",
> which is why I'm using MDB_NEXT_DUP instead of MDB_NEXT in the first place.
> In a nutshell, MDB_NEXT_DUP does the same as MDB_NEXT after a mdb_cursor_del
> call, even though one would expect it not to jump across "key boundaries".
>
> On a side note, prior to 37081325f7356587c5e6ce4c1f36c3b303fa718c / ITS#8406
> this would have resulted in an assertion failure.
>
> You could classify this as a bug and adjust the behaviour to match MDB_NEXT's,
> or you could document the behaviour of mdb_cursor_del regarding the cursor's
> state. Either would be appreciated.

Fixed in mdb.master

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