[erlang-questions] [ANN] LETS - LevelDB-based Erlang Term Storage v0.5.3

[Ciprian Dorin Craciun]

On Sat, Nov 19, 2011 at 17:11, Joseph Norton <norton@REDACTED> wrote:
>
> LETS is an alternative Erlang Term Storage using LevelDB as the storage
> implementation. LETS tries to address some bad properties of ETS and DETS.
> ETS is limited by physical memory. DETS is limited by a 2 GB file size
> limitation and does not implement ordered sets. LETS has neither of these
> limitations. Data can also be automatically compressed using the Snappy
> compression library.
>
> Changes since v0.5.1:
> • Added support to use async thread pool for driver backend
> • Added support for ets match, ets select, and friends
> For testing and comparison purposes, LETS supports three implementations:
> • drv C++ Driver with LevelDB backend (default)
> • nif C++ NIF with LevelDB backend
> • ets Erlang ETS backend
>
> LETS is not intended to be an exact clone of ETS. The currently supported
> ETS APIs are:
> • delete/1
> • delete/2
> • delete_all_objects/1 only ets implementation
> • first/1
> • foldl/3
> • foldr/3
> • info/1 only a subset of items
> • info/2 only a subset of items
> • insert/2
> • insert_new/2 only ets implementation
> • last/1
> • lookup/2
> • lookup_element/3
> • match/1
> • match/2
> • match/3
> • match_delete/2
> • match_object/1
> • match_object/2
> • match_object/3
> • member/2
> • new/2
> • next/2
> • prev/2
> • select/1
> • select/2
> • select/3
> • select_count/2
> • select_delete/2
> • select_reverse/1
> • select_reverse/2
> • select_reverse/3
> • tab2list/1
>
> LETS has been tested solely using QuickCheck and PropEr.
> For further information and instructions to download, please see
> the https://github.com/norton/lets repository on GitHub.
>
> thanks,
>
> Joe N.


    I've thrown a quick look over your code
`https://github.com/norton/lets/blob/master/c_src/lets_nif.cc` -- as I
also want to make a LevelDB binding, but in Go, and I wanted to see
how you did it -- and I was curios about one thing: why you never use
`db->Get` but always for read operations you use
`db->NewIterator(...)`? (I guess it's because it doesn't return a
`Slice` but a `std::string`?)

    Thanks,
    Ciprian.