Skip to content

Commit

Permalink
docs: add sqlite persistence page
Browse files Browse the repository at this point in the history
  • Loading branch information
thunderbiscuit committed Jul 29, 2024
1 parent 5b005c2 commit f950e1f
Show file tree
Hide file tree
Showing 2 changed files with 45 additions and 2 deletions.
2 changes: 1 addition & 1 deletion docs/cookbook/persistence/memory.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ The simplest wallet is one that does _not_ have any persistence. All information

In-memory implies that the addresses the wallet has revealed, the syncing that has been performed including data on the transaction graph will not persist when the wallet is destroyed, and related operations will need to be performed again.

In general, this means performing a `full_sync()` when starting the wallet, because it has no knowledge of which addresses were given out and which scripts still have balances.
In general, this means performing a `full_scan()` when starting the wallet, because it has no knowledge of which addresses were given out and which scripts still have balances.

See our page on the [difference between the full scan and sync operations](../syncing/full-scan-vs-sync.md) for more on this topic.

Expand Down
45 changes: 44 additions & 1 deletion docs/cookbook/persistence/sqlite.md
Original file line number Diff line number Diff line change
@@ -1,3 +1,46 @@
# SQLite Database

TODO
The SQLite persistence is a great default for many use cases, and is a good place to start if you're not sure which persistence to choose from.

By default when using the `bdk_wallet` library, all information about the wallet is held in memory, and will be destroyed upon termination of the process unless saved to persistence.

When information important to the wallet is added to it, the wallet will add it to its staged area. Whenever you want to save this information to persistence, call the `Wallet.persist(&mut db)`.

The operations that affect the wallet and produce a changeset are things like:

- Revealing new addresses
- Sync operations that pick up new UTXOs

Once those things are persisted, upon loading of the database changeset the wallet would be able to rehydrate its [TxGraph](), which includes UTXOs, transaction history, and latest blocks known to the wallet. This means that a wallet that's been loaded from such a persitence will not require a _Full Scan_ but rather simply a _Sync_.

See our page on the [difference between the full scan and sync operations](../syncing/full-scan-vs-sync.md) for more on this topic.

## Example

The sqlite wallet does not require any additional dependencies above the `bdk_wallet` dependency:

```toml
[dependencies]
bdk_wallet = { version = "=1.0.0-beta.1", features = ["rusqlite"] }
```

To create a sqlite-based persisted wallet, simply call the `create_wallet()` with a valid db connection on the wallet builder:

```rust
use bdk_wallet::rusqlite::Connection;

let mut conn = Connection::open(file_path)?;
let wallet = Wallet::create(EXTERNAL_DESCRIPTOR, INTERNAL_DESCRIPTOR)
.network(Network::Signet)
.create_wallet(&mut conn)
.expect("valid wallet and db connection");
```

After performing an operation that returns data that should be persisted, use the `persist()` method on the wallet:

```rust
let address = wallet.next_unused_address(KeychainKind::External);
wallet.persist(&mut conn)?;
```

<br>

0 comments on commit f950e1f

Please sign in to comment.