Fwd: Re: (ITS#7644) inverted MDB_SET_RANGE desired

[hyc@symas.com]

-------- Original Message --------
Subject: Re: (ITS#7644) inverted MDB_SET_RANGE desired
Date: Sat, 27 Jul 2013 14:26:51 -0700
From: Howard Chu <hyc@symas.com>
To: Michiel Visser <vissermc@gmail.com>

Michiel Visser wrote:
> Dear Mr Chu,
>
> Answering your question: in case the found key is equal, you could specify:
> the key parameter *must* stay the untouched (same mv_data pointer), thus no
> extra memory block will be allocated that is basically a duplicate. Maybe it
> is already implemented this way? Important is that this should be documented
> (such that it is frozen). This would make it possible to have my desired
> functionality (and more) without sacrificing any performance (doing another
> unnecessary key comparison).
>
> By the way: the documentation does not tell whether the input key memory
> (mv_data) will stay untouched, in case the output key is different (but its
> size the same or smaller), or that always new memory is allocated for this
> purpose.

1) the library *never* allocates memory to return a value to you. I thought
that was already stated clearly. That's one of the fundamental design
principles of LMDB. You should know this already if you've read the docs.

2) The mdb_cursor_get() doc states explicitly that the object's address is
returned *except* in the case of MDB_SET.

I'm not sure it would be wise to change this at this point in time, people
have been using LMDB for going on 2 years already.

> Thank you for your time, and I want to make clear I really like mdb, and its
> interface :)
>
> Michiel Visser
>
>
> 2013/7/24 Howard Chu <hyc@symas.com <mailto:hyc@symas.com>>
>
>     vissermc@gmail.com <mailto:vissermc@gmail.com> wrote:
>
>         Full_Name: Michiel Visser
>         Version: 2.4.35
>         OS: Linux
>         URL: ftp://ftp.openldap.org/__incoming/ <ftp://ftp.openldap.org/incoming/>
>         Submission from: (NULL) (88.159.211.22)
>
>
>         Feature request:
>         MDB_SET_RANGE is an important option for me (I'm implementing a
>         generic triple
>         store on top of MDB). But I also desire some additions:
>         1) let's call it MDB_SET_RANGE_INV: find key equal of smaller. In
>         theory I could
>         also apply an inverted compare function, but this makes it
>         counter-intuitive
>         ('bigger' actually implying 'smaller'). And I understand I can also use
>         SET_RANGE, followed by a cursor-previous-traversal, but it would
>         require extra
>         logic to check whether the key is already equal, which brings me to my
>         second
>         point:
>
>
>     Extra logic will be required anyway, whether inside liblmdb or in your
>     application. In this case I don't see value in making the library bigger
>     to handle this.
>
>         2) a way to see whether the returned key is equal (to the supplied
>         key), to
>         avoid another call to get/cursor_get, or avoid a manual key compare.
>
>
>     The mdb_cursor_get() function signature is what it is, there's nowhere to
>     return any other parameters. How would you propose to indicate this to the
>     caller?
>
>     --
>        -- Howard Chu
>        CTO, Symas Corp. http://www.symas.com
>        Director, Highland Sun http://highlandsun.com/hyc/
>        Chief Architect, OpenLDAP http://www.openldap.org/__project/
>     <http://www.openldap.org/project/>
>
>


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