orvanta-api 6.5.0

No description provided (generated by Openapi Generator https://github.com/openapitools/openapi-generator)
Documentation
/*
 * Orvanta API
 *
 * No description provided (generated by Openapi Generator https://github.com/openapitools/openapi-generator)
 *
 * The version of the OpenAPI document: 6.5.0
 * Contact: contact@orvanta.cloud
 * Generated by: https://openapi-generator.tech
 */

use crate::models;
use serde::{Deserialize, Serialize};

/// Capabilities : What a migration connector declares it can do. The engine consults this before it starts, so an unsupported operation is refused up front instead of failing part-way through a run. Every field defaults to `false` for a connector that has not declared it -- an absent capability always reads as \"no\", never as an optimistic \"yes\". There is deliberately no per-field \"unknown\" state: unlike a write-permission probe (which can genuinely fail at runtime, and where the engine branches on the difference), a capability is a static statement a connector makes about itself, and \"not declared\" and \"cannot\" produce identical behaviour. Per connection, not per connector type -- two instances of the same connector may answer differently (a DuckDB store over Parquet has a schema, one over a headerless CSV does not).
#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)]
pub struct Capabilities {
    /// The connector can enumerate a dataset's columns authoritatively. `false` means it has no schema authority at all (a headerless CSV, a schema-less collection) -- not that the dataset is missing; the mapping is then reported as unvalidated (a warning) rather than as every field being absent.
    #[serde(rename = "schema_introspection")]
    pub schema_introspection: bool,
    /// The connector can page a dataset by a unique, total order, so batches are a stable partition with no skipped or duplicated rows. `false` makes it unusable as a source and blocks the run. Whether one particular table has such a key (e.g. a primary key) is a separate, per-table runtime error.
    #[serde(rename = "stable_paging")]
    pub stable_paging: bool,
    /// The connector can resolve a dotted `ColumnMapping.source_column` (`profile.address.city`), not just a top-level name. A relational connector declares `false`, and any nested mapping entry is then an `Error`-severity issue naming the offending path.
    #[serde(rename = "nested_source_paths")]
    pub nested_source_paths: bool,
    /// The connector can be a migration target at all. `false` is what \"this target is read-only\" is read from -- distinct from the per-table, per-connection question of whether the current role holds `INSERT`, which is probed separately and reported through `MappingReport`.
    #[serde(rename = "writable")]
    pub writable: bool,
    /// A batch is applied atomically -- all rows or none. `false` does not block a run, but is warned about: a failure can leave a partially applied batch to reconcile by hand.
    #[serde(rename = "transactional_batch")]
    pub transactional_batch: bool,
    /// The connector's page cursor is durable across a process restart. This is only the connector half of checkpoint/resume; the engine does not persist run state yet, so no run is resumable today regardless of this value. The dry-run report says which half is missing.
    #[serde(rename = "resumable_cursor")]
    pub resumable_cursor: bool,
}

impl Capabilities {
    /// What a migration connector declares it can do. The engine consults this before it starts, so an unsupported operation is refused up front instead of failing part-way through a run. Every field defaults to `false` for a connector that has not declared it -- an absent capability always reads as \"no\", never as an optimistic \"yes\". There is deliberately no per-field \"unknown\" state: unlike a write-permission probe (which can genuinely fail at runtime, and where the engine branches on the difference), a capability is a static statement a connector makes about itself, and \"not declared\" and \"cannot\" produce identical behaviour. Per connection, not per connector type -- two instances of the same connector may answer differently (a DuckDB store over Parquet has a schema, one over a headerless CSV does not).
    pub fn new(schema_introspection: bool, stable_paging: bool, nested_source_paths: bool, writable: bool, transactional_batch: bool, resumable_cursor: bool) -> Capabilities {
        Capabilities {
            schema_introspection,
            stable_paging,
            nested_source_paths,
            writable,
            transactional_batch,
            resumable_cursor,
        }
    }
}