synology_apm_repo.sdk.units.saas.drive module

DriveProvider: OneDrive (M365) / Google Drive (GWS) via item_table, built as a SaasWorkloadProvider + RecursiveTree config.

Both platforms share one schema and one provider. Content addressing has no application-layer wrapper: content_object_id points directly at the real file bytes, unlike Mail’s META/fragment reassembly — see _root_folder_id and _build_tree for the one piece of this provider (the synthetic root anchor) that doesn’t fit RecursiveTree’s constructor unchanged.

synology_apm_repo.sdk.units.saas.drive.DRIVE_CONFIG = SaasWorkloadConfig(root_name='/', leaf_kind=<UnitKind.DRIVE_ITEM: 'drive_item'>, tables=('item_table',), tree_factory=<function _build_tree>, assemble=<function _assemble>, object_names={'item_table': ('drive_db',)}, extra_attrs=<function _extra_attrs>, group_attrs=<function SaasWorkloadConfig.<lambda>>, leaf_size=<function _item_size>)

SaasWorkloadConfig behind DriveProvider — one schema shared by OneDrive and Google Drive.

async synology_apm_repo.sdk.units.saas.drive.DriveProvider(repo, version, saas_streams, *, shared=None)

Constructor-style factory over DRIVE_CONFIG — callable exactly like a constructor (await DriveProvider(repo, version, saas_streams)), resolving the service DB via the connector’s own object-name index only, never a scan. shared is accepted only for calling-convention uniformity with units/dispatch.py’s _ProviderFactory — no DRIVE/USER_DRIVE/TEAM_DRIVE sub_type ever offers more than this one candidate, so it is always None in practice. Built as a RecursiveTreeSaasProvider — Drive’s flat, depth-independent item_id addressing is the one SaaS shape units/resolve.py can’t prefix-guide a descent through, so this is the one SaaS factory that needs the direct-lookup capability that subclass provides.