synology_apm_repo.sdk.units.saas.tree_strategy.recursive module

RecursiveTree: Drive’s shape — parent-pointer recursion (parent_folder_id + a root id), one of the two schema shapes every service-level DB in this project expands into (the other being a flat list, optionally grouped by one key).

class synology_apm_repo.sdk.units.saas.tree_strategy.recursive.RecursiveTree(provider, *, table, columns, id_column, parent_column, root_id, folder, display_name, order_by)

Bases: object

Drive’s shape: one table, no group layer — the root is the top of one parent-pointer recursion rooted at root_id. root_id itself never has a row (a synthetic anchor, not a browsable item), but it is a real value parent_folder_id stores for top-level items, so the same WHERE parent_folder_id = ? query handles the root level like any other folder.

async children_of(key, *, offset=0, limit=None)

row_for(key)

None for a folder’s key too, not just a missing one — a folder is never a restorable unit (UnitProvider: unit() is for leaves only), so assemble() must never see its row even though the cache holds it for traversal.

async resolve_id(item_id)

Direct WHERE id_column = ? lookup for item_id, bypassing children_of’s parent-scoped scan entirely — the mechanism SupportsDirectRefLookup needs, since a Drive item’s key is a single, depth-independent id with no parent-scoped children_of call that would find it otherwise. Populates self._rows exactly like children_of does, so a later row_for/unit() call on the same key behaves identically to one reached through ordinary traversal. None if no such row exists.

parent_id_of(key)

The immediate parent’s own id for key — unlike row_for, does not hide a folder’s row, since an ancestor is a folder by definition. None when key’s row isn’t cached yet, or its parent is the synthetic root (no further ancestor to walk to).