lablup / lablup/backend.ai

Adopt DBOpsProvider across API-connected repositories; remove direct ExtendedAsyncSAEngine dependency

Open
#12,077 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Python
Stars
670
Forks
183
Avg merge
15h 13m
Merged PRs (30d)
368

Description

Adopt DBOpsProvider as the single DB-access surface for the repository layer, replacing direct ExtendedAsyncSAEngine usage. The engine is isolated inside DBOpsProvider; repositories obtain session-bound ReadOps/WriteOps via read_ops()/write_ops() and only execute spec types (Creator/Updater/Purger/Querier/BatchQuerier), never raw sessions or raw SQLAlchemy statements.

### Motivation

- Encapsulate the engine and forbid arbitrary SQL at the repository boundary.
- Enforce RBAC scoping at the ops boundary (batch_query_with_scopes vs explicit batch_query_in_global).
- Completes an in-progress direction: role_preset / session / deployment_revision_preset already use DBOpsProvider; ~44 domains have the db_source scaffolding but still take the raw engine.

### Scope

- Target: the ~44 repository domains that already have a db_source but still construct it with the raw db engine (XDBSource(db)).
- Convert each db_source to take DBOpsProvider and rewrite its internals to use read_ops()/write_ops() + spec types.
- For complex multi-table domains (deployment, scheduler, user, scaling_group, ...), scope to the operations wired to current API endpoints (single-table, spec-friendly). Legacy multi-table raw paths may remain for now.
- Reference pattern: repositories/role_preset (repository.py + db_source/db_source.py).

### Out of scope

- Domains without any db_source scaffolding yet (e.g. vfolder, keypair, model_serving, network) — not part of this epic.
- Removing the db field from RepositoryArgs — a final cleanup once every domain migrates.

JIRA Issue: BA-6401

Contributor guide

Open the contributing guide

Research direction

Use repositories/role_preset/repository.py and repositories/role_preset/db_source/db_source.py as the reference pattern. Find the targeted db_source implementations that construct XDBSource(db), then inspect how read_ops()/write_ops() and the Creator, Updater, Purger, Querier, and BatchQuerier specs are used. Done means the scoped API operations use DBOpsProvider rather than the raw engine, while the listed out-of-scope domains and legacy paths remain unchanged.

Written by the indexing model from the issue text.

Assessment

Tech stack
python, sqlalchemy
Domain
api, backend, database
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.