Schemas Reference#

Pydantic schemas for request/response validation.

Schemas are defined under ccat_ops_db_api/schemas/ (UI-context schemas in schemas/ui/schemas.py). For complete schema definitions, see the interactive API documentation at /docs or inspect the source code.

Transfer Overview Schemas (Uniform Operation Model)#

The transfer overview payload is built from the uniform Operation model. The model itself is described in the ops-db Operation model reference and the identity-vs-routing split in the data-transfer two-axes page; the schemas below only describe the API surface.

OverviewOperationBase#

One uniform shape for every operation kind (transfer / unpack / bundling / archive), replacing the old per-stage stripped schemas. It exposes only what an Observer needs to see what is stuck where:

  • id, operation_kind, status, retry_count, start_time, end_time

  • location ids as plain columns — origin_location_id, destination_location_id, data_transfer_package_id, raw_data_package_id (all optional; present only on the kinds that define them). There is no location relationship on the Operation subclasses, so locations are ids, not nested objects.

  • No error text. error_context / failure_error_message are deliberately absent — the overview payload is anonymous, and error detail stays behind the admin-gated failure-history endpoint (ADR-0002).

TransferOverview carries six lists of OverviewOperationBase (active_transfers, unpacking_operations, failed_transfers, failed_unpacks, failed_packages, failed_archiving_operations).

Per-kind count maps#

TransferOverview exposes the canonical operation counts as maps keyed by OperationKind value:

  • operation_counts_by_kind — total operations per kind

  • failed_operation_counts_by_kind — FAILED operations per kind

These are the figures a consumer reads instead of summing the paired per-stage totals; each paired total equals its matching per-kind entry (e.g. total_failed_transfers == failed_operation_counts_by_kind["transfer"]).

Response schemas source from the Operation row#

The detail response schemas keep their field names for UI-contract stability, but their status / retry / error values are sourced from the matching Operation row, not from the artifact’s own (soon-dropped, ops-db #95) columns:

  • DataTransferPackage ← its BundlingOperation (status, retry_count, failure_error_message, error_context)

  • LongTermArchiveTransfer (LTA) ← its ArchiveOperation (status, attempt_count, failure breadcrumbs), resolved per (raw_data_package_id, destination_location_id)

  • RawDataPackage packaging-phase fields ← its PackagingOperation; the package lifecycle fields state / analyze_status are not operation mirrors and stay on the artifact

Key Schema Categories#

Observation Schemas:

  • ExecutedObsUnitCreate

  • ExecutedObsUnitUpdate

  • ExecutedObsUnitResponse

  • ExecutedObsUnitDetail

Data File Schemas:

  • RawDataFileCreate

  • RawDataFileResponse

  • RawDataPackageCreate

  • RawDataPackageResponse

Transfer Schemas:

  • TransferOverviewResponse

  • DataTransferResponse

Authentication Schemas:

  • UserResponse

  • APITokenCreate

  • APITokenResponse

See Swagger UI at /docs for complete schema documentation with examples.