Crates.io | pgdo-lib |
lib.rs | pgdo-lib |
version | |
source | src |
created_at | 2023-10-09 12:14:09.243528 |
updated_at | 2024-12-11 08:01:51.817399 |
description | The convenience of SQLite – but with PostgreSQL (Library package) |
homepage | |
repository | https://github.com/allenap/pgdo |
max_upload_size | |
id | 997953 |
Cargo.toml error: | TOML parse error at line 18, column 1 | 18 | autolib = false | ^^^^^^^ unknown field `autolib`, expected one of `name`, `version`, `edition`, `authors`, `description`, `readme`, `license`, `repository`, `homepage`, `documentation`, `build`, `resolver`, `links`, `default-run`, `default_dash_run`, `rust-version`, `rust_dash_version`, `rust_version`, `license-file`, `license_dash_file`, `license_file`, `licenseFile`, `license_capital_file`, `forced-target`, `forced_dash_target`, `autobins`, `autotests`, `autoexamples`, `autobenches`, `publish`, `metadata`, `keywords`, `categories`, `exclude`, `include` |
size | 0 |
⚠️ ALPHA QUALITY ⚠️
This project is in the early stages of development. It is far from feature complete. It likely contains many bugs and inconsistencies. Documentation is limited or non-existent. It will change in ways that break backwards compatibility. It is not ready for production use.
That said, if you want to try it out, please do! But bear in mind that it is being updated frequently, at least at the time I'm writing this, and you should expect to update it frequently too. Please check out known issues and file new ones here.
Thanks! Gavin.
A Rust library for creating standalone PostgreSQL clusters and databases with a focus on convenience and rapid prototyping – such as one sees using SQLite. Scaling down the developer experience to meet individuals working to build something new, build something rapidly, is a key goal of this project.
It inherits code from the rust-postgresfixture project but deviates from that project's goals and design. Way back, we can trace this tool's origins to ideas in the Python postgresfixture library which saw heavy use in MAAS. That was (and is) a useful tool when experimenting with PostgreSQL. For example we could use it to bring up a cluster to run a development server. However, it came into its own in MAAS's test suites, and was key to making MAAS's test suites faster.
There is a pgdo
command-line application that uses this
library. That may be the easiest way to see how pgdo works.
It's published as pgdo-cli on Crates.io and Lib.rs.
The essential functionality in this crate is in the Cluster
struct and its
implementation. This covers the logic you need to create, run, and destroy
PostgreSQL clusters of any officially supported version (and a few older
versions that are not supported upstream).
use pgdo::{
cluster::{
Cluster, ClusterError,
sqlx::{query, Row}
},
runtime::{
self,
strategy::StrategyLike,
},
};
let tokio = tokio::runtime::Runtime::new()?;
for runtime in runtime::strategy::Strategy::default().runtimes() {
let data_dir = tempfile::tempdir()?;
let cluster = Cluster::new(&data_dir, runtime)?;
cluster.start(&[])?;
assert_eq!(cluster.databases()?, vec!["postgres", "template0", "template1"]);
let rows = tokio.block_on(async {
let pool = cluster.pool(None)?;
let rows = query("SELECT 1234 -- …").fetch_all(&pool).await?;
Ok::<_, ClusterError>(rows)
})?;
let collations: Vec<i32> = rows.iter().map(|row| row.get(0)).collect();
assert_eq!(collations, vec![1234]);
cluster.stop()?;
}
# Ok::<(), ClusterError>(())
However, you may want to use this with the functions in the coordinate
module like [run_and_stop
][coordinate::run_and_stop
] and
[run_and_destroy
][coordinate::run_and_destroy
]. These add locking to the
setup and teardown steps of using a cluster so that multiple processes can
safely share a single on-demand cluster.
If you feel the urge to hack on this code, here's how to get started:
cargo build
.After installing the source (see above) run tests with: cargo test
.
Most tests use pgdo's platform-specific knowledge to test against all of the PostgreSQL runtimes that are installed. When writing new tests, try to mimic the pattern in preexisting tests to ensure that those tests are getting the broadest coverage. Specifically this means:
Install multiple versions of PostgreSQL on your machine. Read on for platform-specific notes.
[runtime::strategy::Strategy::default()
] may be able to automatically find
those installed runtimes – this is the function used by tests.
If pgdo's platform-specific knowledge doesn't cover your platform, have a go
at adding to it. [runtime::strategy::RuntimesOnPlatform
] is a good place to
start.
From https://wiki.postgresql.org/wiki/Apt:
$ sudo apt-get install -y postgresql-common
$ sudo sh /usr/share/postgresql-common/pgdg/apt.postgresql.org.sh -y
$ sudo apt-get install -y postgresql-{9.{4,5,6},10,11,12,13} # Adjust as necessary.
Using Homebrew:
$ brew install postgresql # Latest version.
$ brew install postgresql@{9.{4,5,6},10,11,12,13} # Adjust as necessary.
The packages in this workspace are released together, with the same version number, and they must be uploaded in a certain order.
Cargo.toml
.pgdo-cli/Cargo.toml
, update the dependency on pgdo-lib
to match the
new version from the previous step.cargo update --workspace
to ensure that Cargo.lock
is up to date.-h
output into pgdo-cli's README.md
. On macOS the command
cargo run -- -h | pbcopy
is helpful. Note that --help
output is not
the same as -h
output: it's more verbose and too much for an overview.cargo build && cargo test && cargo doc --no-deps
.$VERSION
."$VERSION
", e.g. git tag v1.0.10
.git push && git push --tags
.cargo publish --package pgdo-lib
.cargo publish --package pgdo-cli
.This package is licensed under the Apache 2.0 License.