Removes the base_uint constructor that took a string. Replaces
that functionality with two free functions named from_hex_text<>.
Use of from_hex_text<> looks like this:
auto v = from_hex_text<uint256>("AAA555");
static_assert (std::is_same<decltype(v), uint256>::value, "Huh!");
from_hex_text<> only operates on base_uint types. At the moment the
list of those types include:
o uint128,
o uint160,
o uint256,
o Directory,
o Account,
o Currency, and
o NodeID.
Using from_hex_text<> with any other types will not compile due to
an enable_if.
This reverts the change that makes RocksDBQuick the default settings for
node_db "type=rocksdb". The quick settings can be obtained by setting
"type=rocksdbquick".
RocksDBQuick settings are implicated in memory over-utilization problems
seen recently.
This removes the old default configuration for the "rocksdb" backend and
replaces it with the configuration that was formerly available using
the experimental backend "rocksdbquick".
The new configuration setting improves the performance of the key/value
database by changing the compaction style and tuning the size parameters for
the typical rippled workload. Testing shows a decrease in I/O spikes for both
reading and writing.
An alternative to the unity build, the classic build compiles each
translation unit individually. This adds more modules to the classic build:
* Remove unity header app.h
* Add missing includes as needed
* Remove obsolete NodeStore backend code
* Add app/, core/, crypto/, json/, net/, overlay/, peerfinder/ to classic build
Makes rippled configurable to support deletion of all data in its key-value
store (nodestore) and ledger and transaction SQLite databases based on
validated ledger sequence numbers. All records from a specified ledger
and forward shall remain available in the key-value store and SQLite, and
all data prior to that specific ledger may be deleted.
Additionally, the administrator may require that an RPC command be
executed to enable deletion. This is to align data deletion with local
policy.
This new factory is intended for benchmarking against the existing RocksDBFactory and has the following differences.
* Does not use BatchWriter
* Disables WAL for writes to memtable
* Uses a hash index in blocks
* Uses RocksDB OptimizeFor… functions
See Benchmarks.md for further discussion of some of the issues raised by investigation of RocksDB performance.
