@nxtedition/rocksdb 5.2.26 → 5.2.27

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@nxtedition/rocksdb",
-  "version": "5.2.26",
+  "version": "5.2.27",
   "description": "A low-level Node.js RocksDB binding",
   "license": "MIT",
   "main": "index.js",
@@ -26,7 +26,6 @@
   },
   "dependencies": {
     "abstract-level": "^1.0.2",
-    "catering": "^2.1.1",
     "module-error": "^1.0.1",
     "napi-macros": "~2.0.0",
     "node-gyp-build": "^4.3.0"

package/deps/rocksdb/rocksdb/README.md

@@ -1,32 +0,0 @@
-## RocksDB: A Persistent Key-Value Store for Flash and RAM Storage
-
-[![CircleCI Status](https://circleci.com/gh/facebook/rocksdb.svg?style=svg)](https://circleci.com/gh/facebook/rocksdb)
-[![TravisCI Status](https://api.travis-ci.com/facebook/rocksdb.svg?branch=main)](https://travis-ci.com/github/facebook/rocksdb)
-[![Appveyor Build status](https://ci.appveyor.com/api/projects/status/fbgfu0so3afcno78/branch/main?svg=true)](https://ci.appveyor.com/project/Facebook/rocksdb/branch/main)
-[![PPC64le Build Status](http://140-211-168-68-openstack.osuosl.org:8080/buildStatus/icon?job=rocksdb&style=plastic)](http://140-211-168-68-openstack.osuosl.org:8080/job/rocksdb)
-
-RocksDB is developed and maintained by Facebook Database Engineering Team.
-It is built on earlier work on [LevelDB](https://github.com/google/leveldb) by Sanjay Ghemawat (sanjay@google.com)
-and Jeff Dean (jeff@google.com)
-
-This code is a library that forms the core building block for a fast
-key-value server, especially suited for storing data on flash drives.
-It has a Log-Structured-Merge-Database (LSM) design with flexible tradeoffs
-between Write-Amplification-Factor (WAF), Read-Amplification-Factor (RAF)
-and Space-Amplification-Factor (SAF). It has multi-threaded compactions,
-making it especially suitable for storing multiple terabytes of data in a
-single database.
-
-Start with example usage here: https://github.com/facebook/rocksdb/tree/main/examples
-
-See the [github wiki](https://github.com/facebook/rocksdb/wiki) for more explanation.
-
-The public interface is in `include/`.  Callers should not include or
-rely on the details of any other header files in this package.  Those
-internal APIs may be changed without warning.
-
-Questions and discussions are welcome on the [RocksDB Developers Public](https://www.facebook.com/groups/rocksdb.dev/) Facebook group and [email list](https://groups.google.com/g/rocksdb) on Google Groups.
-
-## License
-
-RocksDB is dual-licensed under both the GPLv2 (found in the COPYING file in the root directory) and Apache 2.0 License (found in the LICENSE.Apache file in the root directory).  You may select, at your option, one of the above-listed licenses.

package/deps/rocksdb/rocksdb/microbench/README.md

@@ -1,60 +0,0 @@
-# RocksDB Micro-Benchmark
-
-## Overview
-
-RocksDB micro-benchmark is a set of tests for benchmarking a single component or simple DB operations. The test artificially generates input data and executes the same operation with it to collect and report performance metrics. As it's focusing on testing a single, well-defined operation, the result is more precise and reproducible, which also has its limitation of not representing a real production use case. The test author needs to carefully design the microbench to represent its true purpose.
-
-The tests are based on [Google Benchmark](https://github.com/google/benchmark) library, which provides a standard framework for writing benchmarks.
-
-## How to Run
-### Prerequisite
-Install the [Google Benchmark](https://github.com/google/benchmark) version `1.6.0` or above.
-
-*Note: Google Benchmark `1.6.x` is incompatible with previous versions like `1.5.x`, please make sure you're using the newer version.*
-
-### Build and Run
-With `Makefile`:
-```bash
-$ DEBUG_LEVEL=0 make run_microbench
-```
-Or with cmake:
-```bash
-$ mkdir build && cd build && cmake .. -DCMAKE_BUILD_TYPE=Release -DWITH_BENCHMARK
-$ make run_microbench
-```
-
-*Note: Please run the benchmark code in release build.*
-### Run Single Test
-Example:
-```bash
-$ make db_basic_bench
-$ ./db_basic_bench --benchmark_filter=<TEST_NAME>
-```
-
-## Best Practices
-#### * Use the Same Test Directory Setting as Unittest
-Most of the Micro-benchmark tests use the same test directory setup as unittest, so it could be overridden by:
-```bash
-$ TEST_TMPDIR=/mydata/tmp/ ./db_basic_bench --benchmark_filter=<TEST_NAME>
-```
-Please also follow that when designing new tests.
-
-#### * Avoid Using Debug API
-Even though micro-benchmark is a test, avoid using internal Debug API like TEST_WaitForRun() which is designed for unittest. As benchmark tests are designed for release build, don't use any of that.
-
-#### * Pay Attention to Local Optimization
-As a micro-benchmark is focusing on a single component or area, make sure it is a key part for impacting the overall application performance.
-
-The compiler might be able to optimize the code that not the same way as the whole application, and if the test data input is simple and small, it may be able to all cached in CPU memory, which is leading to a wrong metric. Take these into consideration when designing the tests.
-
-#### * Names of user-defined counters/metrics has to be `[A-Za-z0-9_]`
-It's a restriction of the metrics collecting and reporting system RocksDB is using internally. It will also help integrate with more systems.
-
-#### * Minimize the Metrics Variation
-Try reducing the test result variation, one way to check that is running the test multiple times and check the CV (Coefficient of Variation) reported by gbenchmark.
-```bash
-$ ./db_basic_bench --benchmark_filter=<TEST_NAME> --benchmark_repetitions=10
-...
-<TEST_NAME>_cv    3.2%
-```
-RocksDB has background compaction jobs which may cause the test result to vary a lot. If the micro-benchmark is not purposely testing the operation while compaction is in progress, it should wait for the compaction to finish (`db_impl->WaitForCompact()`) or disable auto-compaction.

package/deps/rocksdb/rocksdb/plugin/README.md

@@ -1,43 +0,0 @@
-## Building external plugins together with RocksDB
-
-RocksDB offers several plugin interfaces for developers to customize its behavior. One difficulty developers face is how to make their plugin available to end users. The approach discussed here involves building the external code together with the RocksDB code into a single binary. Note another approach we plan to support involves loading plugins dynamically from shared libraries.
-
-### Discovery
-
-We hope developers will mention their work in "PLUGINS.md" so users can easily discover and reuse solutions for customizing RocksDB.
-
-### Directory organization
-
-External plugins will be linked according to their name into a subdirectory of "plugin/". For example, a plugin called "dedupfs" would be linked into "plugin/dedupfs/".
-
-### Build standard
-
-Currently the only supported build system are make and cmake.
-
-For make, files in the plugin directory ending in the .mk extension can define the following variables.
-
-* `$(PLUGIN_NAME)_SOURCES`: these files will be compiled and linked with RocksDB. They can access RocksDB public header files.
-* `$(PLUGIN_NAME)_HEADERS`: these files will be installed in the RocksDB header directory. Their paths will be prefixed by "rocksdb/plugin/$(PLUGIN_NAME)/".
-* `$(PLUGIN_NAME)_LDFLAGS`: these flags will be passed to the final link step. For example, library dependencies can be propagated here, or symbols can be forcibly included, e.g., for static registration.
-* `$(PLUGIN_NAME)_CXXFLAGS`: these flags will be passed to the compiler. For example, they can specify locations of header files in non-standard locations.
-
-Users will run the usual make commands from the RocksDB directory, specifying the plugins to include in a space-separated list in the variable `ROCKSDB_PLUGINS`.
-
-For CMake, the CMakeLists.txt file in the plugin directory can define the following variables.
-
-* `${PLUGIN_NAME}_SOURCES`: these files will be compiled and linked with RocksDB. They can access RocksDB public header files.
-* `${PLUGIN_NAME}_COMPILE_FLAGS`: these flags will be passed to the compiler. For example, they can specify locations of header files in non-standard locations.
-* `${PLUGIN_NAME}_INCLUDE_PATHS`: paths to directories to search for plugin-specific header files during compilation.
-* `${PLUGIN_NAME}_LIBS`: list of library names required to build the plugin, e.g. `dl`, `java`, `jvm`, `rados`, etc. CMake will generate proper flags for linking.
-* `${PLUGIN_NAME}_LINK_PATHS`: list of paths for the linker to search for required libraries in additional to standard locations.
-* `${PLUGIN_NAME}_CMAKE_SHARED_LINKER_FLAGS` additional linker flags used to generate shared libraries. For example, symbols can be forcibly included, e.g., for static registration.
-* `${PLUGIN_NAME}_CMAKE_EXE_LINKER_FLAGS`: additional linker flags used to generate executables. For example, symbols can be forcibly included, e.g., for static registration.
-
-Users will run the usual cmake commands, specifying the plugins to include in a space-separated list in the command line variable `ROCKSDB_PLUGINS` when invoking cmake.
-```
-cmake .. -DROCKSDB_PLUGINS="dedupfs hdfs rados"
-```
-
-### Example
-
-For a working example, see [Dedupfs](https://github.com/ajkr/dedupfs).

package/deps/rocksdb/rocksdb/port/README

@@ -1,10 +0,0 @@
-This directory contains interfaces and implementations that isolate the
-rest of the package from platform details.
-
-Code in the rest of the package includes "port.h" from this directory.
-"port.h" in turn includes a platform specific "port_<platform>.h" file
-that provides the platform specific implementation.
-
-See port_posix.h for an example of what must be provided in a platform
-specific header file.
-

package/deps/rocksdb/rocksdb/utilities/transactions/lock/range/range_tree/lib/README

@@ -1,13 +0,0 @@
-The files in this directory originally come from
-https://github.com/percona/PerconaFT/.
-
-This directory only includes the "locktree" part of PerconaFT, and its
-dependencies.
-
-The following modifications were made:
-- Make locktree usable outside of PerconaFT library
-- Add shared read-only lock support
-
-The files named *_subst.* are substitutes of the PerconaFT's files, they
-contain replacements of PerconaFT's functionality.
-

package/deps/snappy/snappy-1.1.7/README.md

@@ -1,149 +0,0 @@
-Snappy, a fast compressor/decompressor.
-
-
-Introduction
-============
-
-Snappy is a compression/decompression library. It does not aim for maximum
-compression, or compatibility with any other compression library; instead,
-it aims for very high speeds and reasonable compression. For instance,
-compared to the fastest mode of zlib, Snappy is an order of magnitude faster
-for most inputs, but the resulting compressed files are anywhere from 20% to
-100% bigger. (For more information, see "Performance", below.)
-
-Snappy has the following properties:
-
- * Fast: Compression speeds at 250 MB/sec and beyond, with no assembler code.
-   See "Performance" below.
- * Stable: Over the last few years, Snappy has compressed and decompressed
-   petabytes of data in Google's production environment. The Snappy bitstream
-   format is stable and will not change between versions.
- * Robust: The Snappy decompressor is designed not to crash in the face of
-   corrupted or malicious input.
- * Free and open source software: Snappy is licensed under a BSD-type license.
-   For more information, see the included COPYING file.
-
-Snappy has previously been called "Zippy" in some Google presentations
-and the like.
-
-
-Performance
-===========
-
-Snappy is intended to be fast. On a single core of a Core i7 processor
-in 64-bit mode, it compresses at about 250 MB/sec or more and decompresses at
-about 500 MB/sec or more. (These numbers are for the slowest inputs in our
-benchmark suite; others are much faster.) In our tests, Snappy usually
-is faster than algorithms in the same class (e.g. LZO, LZF, QuickLZ,
-etc.) while achieving comparable compression ratios.
-
-Typical compression ratios (based on the benchmark suite) are about 1.5-1.7x
-for plain text, about 2-4x for HTML, and of course 1.0x for JPEGs, PNGs and
-other already-compressed data. Similar numbers for zlib in its fastest mode
-are 2.6-2.8x, 3-7x and 1.0x, respectively. More sophisticated algorithms are
-capable of achieving yet higher compression rates, although usually at the
-expense of speed. Of course, compression ratio will vary significantly with
-the input.
-
-Although Snappy should be fairly portable, it is primarily optimized
-for 64-bit x86-compatible processors, and may run slower in other environments.
-In particular:
-
- - Snappy uses 64-bit operations in several places to process more data at
-   once than would otherwise be possible.
- - Snappy assumes unaligned 32- and 64-bit loads and stores are cheap.
-   On some platforms, these must be emulated with single-byte loads
-   and stores, which is much slower.
- - Snappy assumes little-endian throughout, and needs to byte-swap data in
-   several places if running on a big-endian platform.
-
-Experience has shown that even heavily tuned code can be improved.
-Performance optimizations, whether for 64-bit x86 or other platforms,
-are of course most welcome; see "Contact", below.
-
-
-Building
-========
-
-CMake is supported and autotools will soon be deprecated.
-You need CMake 3.4 or above to build:
-
-  mkdir build
-  cd build && cmake ../ && make
-
-
-Usage
-=====
-
-Note that Snappy, both the implementation and the main interface,
-is written in C++. However, several third-party bindings to other languages
-are available; see the home page at http://google.github.io/snappy/
-for more information. Also, if you want to use Snappy from C code, you can
-use the included C bindings in snappy-c.h.
-
-To use Snappy from your own C++ program, include the file "snappy.h" from
-your calling file, and link against the compiled library.
-
-There are many ways to call Snappy, but the simplest possible is
-
-  snappy::Compress(input.data(), input.size(), &output);
-
-and similarly
-
-  snappy::Uncompress(input.data(), input.size(), &output);
-
-where "input" and "output" are both instances of std::string.
-
-There are other interfaces that are more flexible in various ways, including
-support for custom (non-array) input sources. See the header file for more
-information.
-
-
-Tests and benchmarks
-====================
-
-When you compile Snappy, snappy_unittest is compiled in addition to the
-library itself. You do not need it to use the compressor from your own library,
-but it contains several useful components for Snappy development.
-
-First of all, it contains unit tests, verifying correctness on your machine in
-various scenarios. If you want to change or optimize Snappy, please run the
-tests to verify you have not broken anything. Note that if you have the
-Google Test library installed, unit test behavior (especially failures) will be
-significantly more user-friendly. You can find Google Test at
-
-  http://github.com/google/googletest
-
-You probably also want the gflags library for handling of command-line flags;
-you can find it at
-
-  http://gflags.github.io/gflags/
-
-In addition to the unit tests, snappy contains microbenchmarks used to
-tune compression and decompression performance. These are automatically run
-before the unit tests, but you can disable them using the flag
---run_microbenchmarks=false if you have gflags installed (otherwise you will
-need to edit the source).
-
-Finally, snappy can benchmark Snappy against a few other compression libraries
-(zlib, LZO, LZF, and QuickLZ), if they were detected at configure time.
-To benchmark using a given file, give the compression algorithm you want to test
-Snappy against (e.g. --zlib) and then a list of one or more file names on the
-command line. The testdata/ directory contains the files used by the
-microbenchmark, which should provide a reasonably balanced starting point for
-benchmarking. (Note that baddata[1-3].snappy are not intended as benchmarks; they
-are used to verify correctness in the presence of corrupted data in the unit
-test.)
-
-
-Contact
-=======
-
-Snappy is distributed through GitHub. For the latest version, a bug tracker,
-and other information, see
-
-  http://google.github.io/snappy/
-
-or the repository at
-
-  https://github.com/google/snappy