On 02. des. 2016 12:26, Tim Uckun wrote:

I am writing a wrapper for liblmdb and one thing I was able to do was to store simple integers and floats as the value into the database. This seems to work pretty well but I am wondering if this is somehow against best practice.

One bad thing about this is that when you are doing a seek or a cursor operation the code does not know what kind of data is at the record. I have some routines to cast them back from the pointers but the user has to know what to cast them to. It would be very handy if the MDB_val struct had a field for metadata, even if it just a byte.

LMDB handles binary data fine. The problem is ordering:

Use a single datatype for each DB, and mdb_set_compare() mdb_set_dupsort() to order data in that DB properly. Or MDB_INTEGERKEY/MDB_INTEGERDUP which do this for unsigned int/size_t.

If that is not feasible and you are mixing different datatypes in a single database, you need to tag each data item so the compare function can figure out how to parse and order them all. Note that a slow compare function can degrade LMDB's performance.

Note that the compare functions may receive unaligned values. Though you can hack alignment 2, 4, or sizeof(size_t) = 4 or 8 by ensuring *every* key and value in a DB has size = multiple of that alignment. Keys always have alignment of at least 2. Hmm, I should add some code so data will too except when both key and data have uneven size.

Requests to add a user-defined argument to the compare functions have been rejected. If you need that, maybe your wrapper can emulate it by setting thread-specific data before calling LMDB, and then your sort function can read that data. That gets cumbersome, though.

If this is all generic, maybe define a DB with meta-info where your wrapper can look up which datatypes (sizes, compare functions, whatever) are in which database.