-------- 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/>