/*
* Hotdata API
*
* Powerful data platform API for instant databases, queries, and analytics.
*
* The version of the OpenAPI document: 1.0.0
* Contact: developers@hotdata.dev
* Generated by: https://openapi-generator.tech
*/
use crate::models;
use serde::{Deserialize, Serialize};
/// QueryResponse : Response body for POST /query Query results are returned immediately along with a `result_id` for later retrieval. Saving the result for later retrieval happens asynchronously in the background. To wait until the saved result can be retrieved, poll `GET /query-runs/{id}` with this response's `query_run_id` and read the run's `status`. Send the `X-Database-Id` header for the database the query ran in: that endpoint is scoped by the header alone and returns 400 without it, including when the query itself was scoped with the `database_id` body field instead. - `\"running\"`: still executing, or still being saved - `\"succeeded\"`: finished. A `result_id` on the run names a saved result that is ready to retrieve, and needs no second check against `GET /results/{id}` — the result is saved and marked ready before the run is marked succeeded, never after. A run carrying no `result_id` saved nothing; see below - `\"failed\"`: the query or the save failed — see the run's `error_message` - `\"interrupted\"`: the run was interrupted before it finished, for example because the server handling it was replaced. Terminal, and safe to retry Read `result_id` off the query run rather than off this body, and treat `succeeded` and \"there is a result to fetch\" as two questions. A run can succeed having saved nothing: when every row was returned here but the result could not be saved for later retrieval, the run is `succeeded` with no `result_id` at all — the field is omitted from the run, not sent as null, so test for its absence — and the run's `warning_message` says why. This response body's `result_id` is issued while the save is still in flight, so on its own it does not mean the result can be retrieved. Do not poll `GET /results/{id}` to wait for readiness. That endpoint returns the result *data*: once the result is ready, a JSON response carries all of it, so a status check made against it transfers the entire result to read one field. It also stops working as the result grows, and the two refusals mean opposite things to a caller: a JSON body that cannot fit the per-fetch memory budget at all is refused with 413 and will be refused again, while one that would fit alone but not alongside the JSON fetches already in flight is refused with 429 and can be retried. `GET /query-runs/{id}` returns no rows at any size.
#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)]
pub struct QueryResponse {
#[serde(rename = "columns")]
pub columns: Vec<String>,
#[serde(rename = "execution_time_ms")]
pub execution_time_ms: i64,
/// Nullable flags for each column (parallel to columns vec). True if the column allows NULL values, false if NOT NULL.
#[serde(rename = "nullable")]
pub nullable: Vec<bool>,
/// Number of rows in *this* response body. Always present. For a large result this is a bounded preview, not the grand total — see `total_row_count` and `truncated`.
#[serde(rename = "preview_row_count")]
pub preview_row_count: i64,
/// Unique identifier for the query run record (qrun...).
#[serde(rename = "query_run_id")]
pub query_run_id: String,
/// Unique identifier for retrieving this result via GET /results/{id}. When non-null, the result is being persisted asynchronously. Null only when the result fit entirely in this response (`truncated: false`) but could not be persisted for later retrieval — see the `warning` field. A `truncated: true` response ALWAYS carries a non-null, resolvable `result_id`: a truncated result that cannot be persisted fails the request with a retryable HTTP 503 (`PERSISTENCE_UNAVAILABLE`, with a `Retry-After` header) rather than returning a partial body with a dead ticket.
#[serde(
rename = "result_id",
default,
with = "::serde_with::rust::double_option",
skip_serializing_if = "Option::is_none"
)]
pub result_id: Option<Option<String>>,
/// **Deprecated** — use `preview_row_count` (rows in this body) and `total_row_count` (grand total) instead. Retained as a back-compat alias and always equal to `preview_row_count`; for a truncated result it is the preview count, *not* the grand total — read `total_row_count` for that. Will be removed in a future release once clients migrate.
#[serde(rename = "row_count")]
pub row_count: i32,
/// Array of rows, where each row is an array of column values. Values can be strings, numbers, booleans, or null.
#[serde(rename = "rows")]
pub rows: Vec<Vec<serde_json::Value>>,
/// Grand total rows in the full result. Present (and equal to `preview_row_count`) when the whole result fit in this response; `null` while a truncated result is still being persisted. When `null`, read the authoritative total from `GET /v1/query-runs/{id}` (`row_count`) or the `X-Total-Row-Count` header on `GET /v1/results/{id}`.
#[serde(
rename = "total_row_count",
default,
with = "::serde_with::rust::double_option",
skip_serializing_if = "Option::is_none"
)]
pub total_row_count: Option<Option<i64>>,
/// True when `rows` is a bounded preview of a larger result. Fetch the full result via `result_id`.
#[serde(rename = "truncated")]
pub truncated: bool,
/// Warning message if result persistence could not be initiated. Present only when the full result is returned inline (`truncated: false`) but could not be persisted: `result_id` is then null and the result cannot be re-fetched later, though every row is in this response. A truncated result never carries a warning — if it cannot be persisted the request fails with a retryable HTTP 503 (`PERSISTENCE_UNAVAILABLE`, with a `Retry-After` header) instead.
#[serde(
rename = "warning",
default,
with = "::serde_with::rust::double_option",
skip_serializing_if = "Option::is_none"
)]
pub warning: Option<Option<String>>,
}
impl QueryResponse {
/// Response body for POST /query Query results are returned immediately along with a `result_id` for later retrieval. Saving the result for later retrieval happens asynchronously in the background. To wait until the saved result can be retrieved, poll `GET /query-runs/{id}` with this response's `query_run_id` and read the run's `status`. Send the `X-Database-Id` header for the database the query ran in: that endpoint is scoped by the header alone and returns 400 without it, including when the query itself was scoped with the `database_id` body field instead. - `\"running\"`: still executing, or still being saved - `\"succeeded\"`: finished. A `result_id` on the run names a saved result that is ready to retrieve, and needs no second check against `GET /results/{id}` — the result is saved and marked ready before the run is marked succeeded, never after. A run carrying no `result_id` saved nothing; see below - `\"failed\"`: the query or the save failed — see the run's `error_message` - `\"interrupted\"`: the run was interrupted before it finished, for example because the server handling it was replaced. Terminal, and safe to retry Read `result_id` off the query run rather than off this body, and treat `succeeded` and \"there is a result to fetch\" as two questions. A run can succeed having saved nothing: when every row was returned here but the result could not be saved for later retrieval, the run is `succeeded` with no `result_id` at all — the field is omitted from the run, not sent as null, so test for its absence — and the run's `warning_message` says why. This response body's `result_id` is issued while the save is still in flight, so on its own it does not mean the result can be retrieved. Do not poll `GET /results/{id}` to wait for readiness. That endpoint returns the result *data*: once the result is ready, a JSON response carries all of it, so a status check made against it transfers the entire result to read one field. It also stops working as the result grows, and the two refusals mean opposite things to a caller: a JSON body that cannot fit the per-fetch memory budget at all is refused with 413 and will be refused again, while one that would fit alone but not alongside the JSON fetches already in flight is refused with 429 and can be retried. `GET /query-runs/{id}` returns no rows at any size.
pub fn new(
columns: Vec<String>,
execution_time_ms: i64,
nullable: Vec<bool>,
preview_row_count: i64,
query_run_id: String,
row_count: i32,
rows: Vec<Vec<serde_json::Value>>,
truncated: bool,
) -> QueryResponse {
QueryResponse {
columns,
execution_time_ms,
nullable,
preview_row_count,
query_run_id,
result_id: None,
row_count,
rows,
total_row_count: None,
truncated,
warning: None,
}
}
}