New Release: kvdb-rocksdb about parity-common HOT 6 CLOSED

This is only relevant when using
rocksdb::DBWithThreadMode::open_cf_descriptors_with_ttl() with multiple
column families.

We're not using this method and hence it's not a security release for kvdb-rocksdb.

from parity-common.

+1 another reason is rocksdb depends on zstd which not follows semantic versioning, 0.18.0 still use old version which will conflict with latest one

from parity-common.

+1 another reason is rocksdb depends on zstd which not follows semantic versioning, 0.18.0 still use old version which will conflict with latest one

Substrate doesn't use zstd feature of rocksdb. Even if it's enabled, it will use snappy compression for compatibility reasons.

from parity-common.

+1 another reason is rocksdb depends on zstd which not follows semantic versioning, 0.18.0 still use old version which will conflict with latest one

Substrate doesn't use zstd feature of rocksdb. Even if it's enabled, it will use snappy compression for compatibility reasons.

But if other crate enable zstd, Substrate's one will enable it too, then two zstd conflict each other, this Cargo bad

from parity-common.

But if other crate enable zstd

why would another crate use rocksdb directly instead of kvdb-rocksdb and enable zstd feature of it knowing it's useless if snappy is also enabled?

from parity-common.

But if other crate enable zstd

why would another crate use rocksdb directly instead of kvdb-rocksdb and enable zstd feature of it knowing it's useless if snappy is also enabled?

zstd is default feature of rocksdb https://github.com/rust-rocksdb/rust-rocksdb/blob/master/Cargo.toml#L23
so if you don't default-feature=false, it will enable by default

We're using monorepo, a blockchain-browser app use RocksDB directly for backend storage like normal web app, that's why we found the conflicts

from parity-common.