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