| cli |
|
|
| db.rs |
Database handling
Components typically use SQLite to handle their storage needs. Databases are opened in `WAL`
mode, which essentially allows for multiple readers, but only one writer at a time.
(https://www.sqlite.org/wal.html). The `Databases` struct is responsible for managing
connections and avoids `SQLITE_BUSY` errors.
SQLite is typically very fast, but some queries can be slow and operations that run many
queries can be slow even if each individual query is fast. The `interrupt_support` crate can
help deal with this, by giving you ways to interrupt in-progress database operations. |
21617 |
| error.rs |
Error handling for the component.
Components generally create 2 error enums: one for internal usage and one for the public APIs.
The internal errors can have lots of variants and store any details that you might want to use.
The public errors can limit the number of variants to the ones consumers actually care about.
In general, the Rust code will use the internal errors. The public API, defined in `lib.rs`,
converts internal errors to public errors. |
5967 |
| http.rs |
Http client example
This creates a TODO item from a GitHub issue. This is kind-of silly, but you should still be
able to use the code as a starting point for your component's HTTP requirements. |
2430 |
| lib.rs |
Top-level module, see README.md for an overview of what's going on in this component.
`lib.rs` defines the main public API for the component. |
7624 |
| README.md |
This crate is an example Rust component. It aims to show how components are generally structured |
891 |
| schema.rs |
Database initialization, schema and migration code
The `sql_support` crate provides decent support for SQLite migrations.
The basic system is:
* Define the current schema at the top of the module, alongside a version number
* If you change the schema then:
* Update the current schema
* Bump the version number
* Add the migration as a case in the `upgrade_from` function |
4626 |