mirror of
https://github.com/hanzo-ds/rs.git
synced 2026-10-30 20:49:56 +00:00
zeekay
86788566d1
Cut from the upstream v0.13.3 release tag (not HEAD) so this is a pure
rename with no behaviour change. v0.13.3 is what our consumers already
resolve to: insights/rust's Cargo.lock pins clickhouse 0.13.3 and its
manifest already declares `datastore` at 0.13.x.
The load-bearing change is the HTTP auth header rename. The Datastore
server reads only X-Datastore-User / X-Datastore-Key; the upstream names
return `401 Code: 194 Authentication failed`. Every un-renamed HTTP
client is therefore unable to authenticate at all — this is a
correctness fix, not branding.
- crate `clickhouse` -> `datastore`, `clickhouse-derive` -> `datastore-derive`;
versions preserved exactly (0.13.3 / 0.2.0).
- derive macro emits `datastore::Row` in lockstep, so downstream
`#[derive(Row)]` keeps resolving.
- User-Agent reports `datastore-rs/{version}`.
- test-harness env vars CLICKHOUSE_* -> DATASTORE_*; compose uses
ghcr.io/hanzoai/datastore with /etc/datastore-server config paths.
- doc links point at docs.hanzo.ai/datastore.
- `publish = false`: the `datastore` name on crates.io belongs to an
unrelated crate, so consume this by git tag, never by version range.
CHANGELOG is truncated to a fork notice rather than find-replaced —
rewriting upstream release history would manufacture changes Datastore
never shipped. References to upstream issues keep their numbers.
57 lines
1.8 KiB
Rust
57 lines
1.8 KiB
Rust
use datastore_derive::Row;
|
|
use serde::{Deserialize, Serialize};
|
|
use uuid::Uuid;
|
|
|
|
use datastore::sql::Identifier;
|
|
use datastore::{error::Result, Client};
|
|
|
|
/// Besides [`Client::with_option`], which will be applied for all requests,
|
|
/// `session_id` (and other settings) can be set separately for a particular `query`, `insert`,
|
|
/// or when using the `inserter` feature.
|
|
///
|
|
/// This example uses temporary tables feature to demonstrate the `session_id` usage.
|
|
///
|
|
/// # Important
|
|
/// With clustered deployments, due to lack of "sticky sessions", you need to be connected
|
|
/// to a _particular cluster node_ in order to properly utilize this feature, cause, for example,
|
|
/// a round-robin load-balancer will not guarantee that the consequent requests will be processed
|
|
/// by the same Datastore node.
|
|
///
|
|
/// See also:
|
|
/// - https://docs.hanzo.ai/datastore/sql-reference/statements/create/table#temporary-tables
|
|
/// - upstream issue #21748
|
|
/// - `examples/datastore_settings.rs`.
|
|
#[tokio::main]
|
|
async fn main() -> Result<()> {
|
|
let table_name = "chrs_session_id";
|
|
let session_id = Uuid::new_v4().to_string();
|
|
|
|
let client = Client::default()
|
|
.with_url("http://localhost:8123")
|
|
.with_option("session_id", &session_id);
|
|
|
|
client
|
|
.query("CREATE TEMPORARY TABLE ? (i Int32)")
|
|
.bind(Identifier(table_name))
|
|
.execute()
|
|
.await?;
|
|
|
|
#[derive(Row, Serialize, Deserialize, Debug)]
|
|
struct MyRow {
|
|
i: i32,
|
|
}
|
|
|
|
let mut insert = client.insert(table_name)?;
|
|
insert.write(&MyRow { i: 42 }).await?;
|
|
insert.end().await?;
|
|
|
|
let data = client
|
|
.query("SELECT ?fields FROM ?")
|
|
.bind(Identifier(table_name))
|
|
.fetch_all::<MyRow>()
|
|
.await?;
|
|
|
|
println!("Temporary table data: {data:?}");
|
|
Ok(())
|
|
}
|