Background
We are leveraging RocksDB in managed (C#) applications via the RocksDBSharp application library. That library exposes much of the essential RocksDB functionality that we required. But not all.
Problem
However, ExportColumnFamily() and CreateColumnFamilyWithImport() methods are not exposed in RocksDB's public C-style API; therefore, they cannot be leveraged by non-native applications, such as exposed in the RocksDB-Sharp application/wrapper (for managed C# use). These methods would be extremely useful, if not essential, for our purposes; we would prefer not to have to maintain our own private fork of the RocksDBSharp repo to leverage this enhancement, nor would we prefer to call separately into the RocksDB layer via P/Invoke or other methods to leverage the methods missing from RocksDBSharp.
Proposed Changes
We'd like to see RockstDBSharp enhanced to expose the ExportColumnFamily() and CreateColumnFamilyWithImport() methods. For proper usage, by any external calling application, this will require additional support functions (for the marshalling of the LiveFileMetadata structure and the ImportColumnFamilyOptions classes/structs via properties and objects from native to C# applications and back) to be implemented and exposed in the RocksDBSharp as well. We have already initiated a feature request proposal in the RocksDB repo for these functions in the public C-style API () and a proposed PR.
Proof of Concept
We have prototyped a working RocksDBSharp build with changes to the RocksDBSharp project that leverages the proposed changes to the RocksDB C-style API on Windows (and VS2022) to expose the ExportColumnFamily() and CreateColumnFamilyWithImport() methods (plus, their supporting methods as well). Unit tests are still in development.
Feedback
We would like to solicit feedback from this community about the feasibility of this Feature Request being integrated into the master branch? We believe that this would be a reasonable feature to implement in RocksDBSharp that others would benefit from as well, but do others think that is true? And if deemed worthy, what would it take to get these proposed changes in?
Background We are leveraging RocksDB in managed (C#) applications via the RocksDBSharp application library. That library exposes much of the essential RocksDB functionality that we required. But not all.
Problem However,
ExportColumnFamily()andCreateColumnFamilyWithImport()methods are not exposed in RocksDB's public C-style API; therefore, they cannot be leveraged by non-native applications, such as exposed in the RocksDB-Sharp application/wrapper (for managed C# use). These methods would be extremely useful, if not essential, for our purposes; we would prefer not to have to maintain our own private fork of the RocksDBSharp repo to leverage this enhancement, nor would we prefer to call separately into the RocksDB layer via P/Invoke or other methods to leverage the methods missing from RocksDBSharp.Proposed Changes We'd like to see RockstDBSharp enhanced to expose the
ExportColumnFamily()andCreateColumnFamilyWithImport()methods. For proper usage, by any external calling application, this will require additional support functions (for the marshalling of theLiveFileMetadatastructure and theImportColumnFamilyOptionsclasses/structs via properties and objects from native to C# applications and back) to be implemented and exposed in the RocksDBSharp as well. We have already initiated a feature request proposal in the RocksDB repo for these functions in the public C-style API () and a proposed PR.Proof of Concept We have prototyped a working RocksDBSharp build with changes to the RocksDBSharp project that leverages the proposed changes to the RocksDB C-style API on Windows (and VS2022) to expose the
ExportColumnFamily()andCreateColumnFamilyWithImport()methods (plus, their supporting methods as well). Unit tests are still in development.Feedback We would like to solicit feedback from this community about the feasibility of this Feature Request being integrated into the master branch? We believe that this would be a reasonable feature to implement in RocksDBSharp that others would benefit from as well, but do others think that is true? And if deemed worthy, what would it take to get these proposed changes in?