bh1xuw / rust-rocks Goto Github PK

View Code? Open in Web Editor NEW

46.0 3.0 7.0 1.21 MB

Make RocksDB really rocks! The Rust style API.

License: Apache License 2.0

Makefile 0.06% Rust 71.80% C++ 28.15%

rocksdb database lsm-tree

rust-rocks's People

Contributors

Stargazers

Watchers

Forkers

andelf polachok lipaul sinhasantos winstonewert sezaru iq-scm

rust-rocks's Issues

Title of README does not render correctly on crates.io

See https://crates.io/crates/rocks. Perhaps the Markdown supported by crates.io is a bit different? It seems other projects have found a solution that works for both, however.

Segfault using column families

The following code segfaults:

use rocks::rocksdb::*;
fn main() {
    let database = DB::open_with_column_families(
        &Options::default_instance(),
        "foobar",
        vec![
            ColumnFamilyDescriptor::new(
                "default",
                ColumnFamilyOptions::new()
            ),
        ]
    ).unwrap();
}

The problem is that the database gets dropped before the column factory handles.

Issue with iterator and lifetimes

Consider the implementation of next() for Iterator

fn next(&mut self) -> Option<Self::Item> {
        if self.is_valid() {
            let k = self.key();
            let v = self.value();
            self.next();
            Some((k, v))
        } else {
            None
        }
    }

The self.next() line invalidates the returned references from self.key() and self.value(). Thus this iterator is always returning bad references.

But why didn't Rust catch this?

pub fn key(&self) -> &'a [u8] {

key (and value) claims to return a reference with lifetime 'a. But this isn't really accurate, as it should only be valid until the next &mut call on self (probably on .next()). Rust doesn't catch the problem because of the unsafe code used to implement the function (obviously unavoidable.)

Cache needs to be shareable

Hello, Cache can be used in multiple column families or databases at the same time.

Currently the functions that receive a Cache receive it as Option<Cache> as parameter, moving the cache as consequence.

I propose that we change it to Option<&Cache> so we send it by reference and allow using the same cache in multiple locations.

I have a commit in my fork with this change: sezaru@ae1eb65

It seems to work great, but maybe there is a better solution or some problem with it, so I'm first creating this issue to ask your opnion, and if it is ok, I will create a PR then.

TODOs / Feature set compared with C++ RocksDB

static-link with zlib overwrites src(submodule) files

The ./configure scripts overwrites Makefile and zconf.h.

Makes a dirty repo dir.

Relationship between the rocksdb crate or other rust-rocksdb forks?

You're aware that a reasonably mature RocksDB crate already exists, right? I just thought I'd point it out...

Working with RocksDB on Win10

Hi everyone. I started to examine Rocksdb but recieving an error compiling hw project, having rocks="0.1" in [dependencies] of Cargo.toml.
I asked about this at the official forum, and was told that Rocksdb might not work on Windows10 .
Is there a way to use Rocksdb on Windows10, or im doing something else wrong?

Link with circular reference among 2 crates under Linux in Rust?

This issue is to track how to solve circular reference link error under Linux.

MacOS(llvm-lld) is OK to handle the circular references while linking.

GCC reuqire that you put the object files and libraries in the order that they depend on each other.

ld accepts the following options:

-( archives -)
--start-group archives --end-group

The specified archives are searched repeatedly until no new undefined references are created.

Yet, rust won't wrap user-defined in repeated search group.

Option 1

Use lld under Linux:

RUSTFLAGS="-C link-arg=-fuse-ld=lld" cargo test

Option 2

Use shell wrapper: #12

Memory Leaks

NOTE:

NO leaks if you don't use customized comparator or compaction filter.

rocks-sys/rocks/options.cc:

rocks_cfoptions_set_comparator_by_trait
rocks_cfoptions_set_compaction_filter_by_trait

Both leak 16 bytes when used in Option.set_xxx. (== sizeof A Rust Trait Object)

Reason:

In C++, these 2 options are static pointers, instead of std::shared_ptr. (They are to be used across many CFs.)

In Rust, use Box<Box<T>> as *mut Box<T> (1 pointer size = sizeof void*). Box::into_raw used without Box::from_raw.

Possible Solution:

Attach Comparator & CompactionFilter lifetime to DB or sth.

Questions about the project

First of all, thanks for the library!

I'm developing a rocksdb wrapper for Elixir language.

Currently, I'm using rust-rocksdb library instead of directly wrapping into C/C++ (for safety reasons). I recently found out about your library and became interested in maybe replace rust-rocksdb with it for my wrapper.

I just have some questions that I hope you can answer if you don't mind.

Is this library a long-term project? I saw that you already have more functionality implemented compared to rust-rocksdb and also I find your organization way better (ex. You separate database options from column family options) but I was wondering if you pretend to continue develop this project in the future;
One issue that I have with rust-rocksdb and I would probably have with your library too is lifetime objects.

For example, you need to define a lifetime to a Iterator struct, but if I want to return that iterator pointer via my wrapper (so I can use the iterator in Elixir code) it is not possible because of the lifetime.

As far as I understand, the only reason for the lifetime in Iterator is because of the PhantomData field:
_marker: PhantomData<&'a ()>.

Is it possible to provide an alternative to this without this field so Rust will not complain when I try to return it? Or maybe you know some other way around it that I'm not aware.

Thanks you for your time!