Sha256: d456f2cbf231c200a4aa69ccd1ebde9ab590b221533fb15dd08be9702463d26a
Contents?: true
Size: 1.67 KB
Versions: 2
Compression:
Stored size: 1.67 KB
Contents
= Storage There is support for different storage backends, currently there are two. Each backend can be used with sqlite, postgres or mysql. == Backends === UTXO The `utxo` backend stores only the minimum amount of information needed to validate new blocks, namely the `Unspent TX Outputs`. So it can be used to independently validate the whole blockchain as it goes, but it cannot query old data or serve blocks to peers. There is however a way to tell it specific addresses for which it will keep the history (the ones in your wallet). === Sequel The `sequel` backend stores the whole blockchain into a fully normalized SQL DB. It can be used to run arbitrary queries on the blockchain data, but the database gets huge and it takes a very long time to do an initial sync. It is used to run http://webbtc.com and there are also postgres dumps to get you started faster on http://dumps.webbtc.com. == Config For examples that require storage backends, you can specify them using a string containing the backend name and a configuration string. The default backend is +utxo::sqlite:~/.bitcoin-ruby/<network>blocks.db+, which is a sqlite database called +blocks.db+ in a directory named after the network you're using, inside your homedir. sequel::sqlite:/ # in-memory sequel::sqlite://bitcoin.db sequel::sqlite:///tmp/bitcoin.db sequel::postgres:/bitcoin sequel::postgres://<user>:<pass>@<host>:<port>/<database> == Custom Backends To implement a custom backend you need to inherit from Bitcoin::Storage::Backends::StoreBase and implement the methods defined there. When returning blocks/tx, you should wrap them in Bitcoin::Storage::Models objects. See the `dummy` backend for a simple example.
Version data entries
2 entries across 2 versions & 1 rubygems
Version | Path |
---|---|
bitcoin-ruby-0.0.6 | doc/STORAGE.rdoc |
bitcoin-ruby-0.0.5 | doc/STORAGE.rdoc |