synology_apm_repo.sdk.catalog.connection module¶

Connection: one backup source (a db/connection_config row) and its own cheap enumeration query, connections() — a plain SQLite read, never touching Pool or Composition, sorted by display_name since connection_config has no chronological field. display_name extraction (_connection_display_name) is a first-class output here, not an afterthought — CLI/TUI show only display_name/subtitle/ attrs in the default (non-diagnostic) mode; raw ids stay internal. The sibling Workload/Version entities and their own display-name/status extraction (_device_display_name/_saas_display_name, _version_epoch) live in catalog/workload.py/catalog/version.py instead — not catalogued here.

How a workload is linked to a connection: workload_config carries no connection_config_id column of its own — the only table with both workload_id and connection_config_id is copy_target_version, so that join is the actual source of truth _workload_ids_by_connection/ _namespace_by_workload below use (catalog/workload.py’s own _workload_ids_for_connection relies on the same join, in its single-connection form).

class synology_apm_repo.sdk.catalog.connection.Connection(connection_config_id, connection_id, display_name, namespaces, workload_count, version_count)¶

Bases: object

One backup source: a db/connection_config row, i.e. a distinct originating APM this repository has received Copy data from.

connection_config_id: ConnectionConfigId¶

connection_id: ConnectionId¶

display_name: str¶

namespaces: tuple[str, ...]¶

workload_count: int¶

version_count: int¶

async synology_apm_repo.sdk.catalog.connection.connections(repo)¶

Sorted by display_name (case-insensitive) — unlike versions, connection_config has no chronological field a collection order could instead follow. Per-connection enrichment (workload ids, namespaces, version counts) is batched across every row collected below in one shot each, mirroring versions’s own two-pass “collect rows, then batch-resolve” shape.