Open mneumann opened 9 years ago
It would be great to have a test case for it as there is a unsafe conversion from Ordering
to u8
, even though it's very unlikely will change soon
Please see my second commit. There, I assert that the ordering conversion is as expected.
As you use u64
as an example how to use those functions may I also ask you to add a doc comment for them with a note that LMDB has a smart internal integer sorting (it doesn't depends on size of integer), which means if the key has a fixed size it's preferred to set DbIntKey
flag instead of setting a custom sort function?
I apologize I haven't though of it earlier.
I will add a doc comment, but I don't know much about LMDB's internal integer sorting. I only expect it to work for usize and probably u32. Would it work for u16 or u8, too? Where is this documented in LMDB?
Btw, I found out that when you want to sort keys that are > u64 (for example a (u64, u64) tuple), you can do that by encoding it as big-endian and use the string sort of LMDB. This was before you added set_cmp() and set_dupsort() functions, which would be the prefered way.
I've actually expected it to work only with u32
/u64
depending on system but here is a clarification, see MDB_INTEGER
section
which would be the preferred way
Tuples are interesting case, I'd try to go with LMDB builtin int comparison
Use it like this (for every type that implement FromMdbValue and Ord):