[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#7570) fix MDB_GET_MULTIPLE and MDB_NEXT_MULTIPLE behaviour
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#7570) fix MDB_GET_MULTIPLE and MDB_NEXT_MULTIPLE behaviour
- From: hyc@symas.com
- Date: Mon, 15 Apr 2013 20:42:45 GMT
- Auto-submitted: auto-generated (OpenLDAP-ITS)
claude.brisson@gmail.com wrote:
> On Mon, 15 Apr 2013 20:01:01 GMT
> hyc@symas.com wrote:
>
>> Your patch changes the meaning of these operations.
>> GET_MULTIPLE/NEXT_MULTIPLE is *only* for duplicate data and already
>> documented as such.
>
> The documentation in the header never states that MULTIPLE operations
> should *fail* on singletons. One could expect that the sentence "Return
> all the duplicate data items at the current cursor position" means
> that singletons will *also* be returned, without having to resort to a
> second call in case of failure.
>
>> Your patch makes them return non-duplicate data. This is a
>> fundamental change in an established behavior. A complete break,
>> actually; it will return data that doesn't match the key that the
>> client requested. It is completely wrong.
>
> I'm sorry if it broke something and made you loose your time, I was
> trying to help here. But the only change is to return singletons
> instead of MDB_NOTFOUND - the data will always match the key.
No. This is in your patch:
@@ -4803,7 +4806,7 @@ mdb_cursor_get(MDB_cursor *mc, MDB_val *key, MDB_val *data,
if (!(mc->mc_flags & C_INITIALIZED))
rc = mdb_cursor_first(mc, key, data);
else
- rc = mdb_cursor_next(mc, key, data, MDB_NEXT_DUP);
+ rc = mdb_cursor_next(mc, key, data, MDB_NEXT_NODUP);
if (rc == MDB_SUCCESS) {
if (mc->mc_xcursor->mx_cursor.mc_flags & C_INITIALIZED) {
MDB_cursor *mx;
So you've made it return non-matching data.
> Maybe I missed something, here. But I wonder why the client code should
> at any point *expect* truly duplicate data.
That is the sole purpose of these options.
Re-read the description:
MDB_GET_MULTIPLE, /**< Return all the duplicate data items at the
current
cursor position. Only for #MDB_DUPFIXED */
If the current cursor position is a singleton, then you already have its data
if you positioned the cursor using (&key, &data) so there is no need to make
any further calls anyway.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/