Version 0.11.0

This release is breaking. Here is what has been updated compared to the v0.8 releases.

No more PolyDatabase

The PolyDatabase was a non-typed heed database that was forcing library users to always specify the en/decoder to store/read entries from the database. It was sometimes confusing and made the codebase harder to maintain due to the Database that was mirroring the PolyDatabase method but with already known en/decoders.

The PolyDatabase can now be replaced by the UntypedDatabe combined with the newly introduced remap_key/data_type or remap_types methods.

Two new BytesDecode and BytesEncode traits

The BytesDecode and BytesEncode traits have been reworked to allow users to return error messages now. It was a big source of frustration for users only to know that an en/decoding was failing without knowing anything about the error happening.

Replacing zerocopy by bytemuck

We used the zerocopy crate since the first version of heed, the crate was named zerocopy-lmdb at first!
This is now the past as we switch from it, we found out that proposing changes to the zerocopy crate was more complex than proposing a change to the bytemuck crate hosted on Github. I am really impressed by the work done by both crate maintainers and grateful to people working on the zerocopy crate, nothing political. You can read more about that on the related issue.

A faster Database::len method

Thanks to @Keats this is now O(1) to get the number of entries in a database. The previous heed version was O(N) as it was iterating through the whole tree to count the length.

Windows support

We now compile on Windows 🎉

Thanks to @maroider and @gentoid for your help!

Typed transactions

We support typed transactions, it is useful when you need to work with multiple environments and you don't want to shuffle the transactions between them.

Take a look at an example here.

v0.5.0

We now support infinite nested write transactions.

It is a feature that LMDB provides, it allows to create a write transaction inside of another one, when a nested transaction is committed, nothing is saved consistently until the main write transaction (the parent) is committed.

Nested transactions can be aborted without aborting the main one, it can be useful to create nested jobs that can fail.

You can see an example usage of nested transactions in the examples folder.