Re: using cursors in LDBM back end with gdbm (ITS#450)

[Kurt@OpenLDAP.org]

[added openldap-its back to cc list so comments will
follow issue]

At 01:15 AM 2/11/00 +0000, Mark Adamson wrote:
>> In 1.2 or devel codes?   In 1.2, the code works because the
>> caller copies key to last before calling ldbm_nextkey().
>> In devel, the code appears to be broken in that back-ldbm is
>> assuming cursor support which LDBM doesn't provide.  The
>> solution here is to either have back-ldbm manage a last key
>> or have LDBM manage the last key as a "cursor".  The cursor
>> approach would be better as it makes LDBM job is to deal
>> with differnet capabilities of the underlying database engine.
>> 
>
>I was working in the devel tree, libraries/libldbm/ldbm.c  vers 1.36.

I didn't want to assume such.

>  I would argue that the front ends should NOT attempt cursor support,
>it should be left to the back end database, such as gdbm.  Different
>databases will cursor in different ways, and they should be allowed to do
>it however they want, using cursors opaque to the calling functions. For
>that reason, I was surprised to find that the LDBMcursor was an "int" and
>not a "void *" in include/ldbm.h

The LDBM/gdbm code was never designed to called with a
cursor, hence the int.  When I replaced ldbmcat with slapcat,
I forgot this.  I applied a fix which should resolve it.

>  Thumbing through gdbm, I found that gdbm_nextkey() does need the entire
>Datum structure, ie both the dptr and the dsize fields, in the cursor.
>Trying to save an entire Datum structure in an "int" cursor was, um,
>trying.

See my fix.

Note: the LDBM library will fade away.  The ldbm*() routines *should*
only used by back-ldbm and hence could be integrated directly into
the backend.  (Tools are no longer LDBM specific).  However, back-bdb2
still uses LDBM... but that not going to true for long... (I hope).

Kurt