Problem Statement
PositionDBConnector → UserDBConnector → DBConnector forms a three-level deep inheritance chain. This is a fragile "diamond" pattern: PositionDBConnector inherits from UserDBConnector which inherits from DBConnector, but both PositionDBConnector and DBConnector create their own engine instances.
Evidence
# quantara/web_app/db/crud/position.py:22
class PositionDBConnector(UserDBConnector): # inherits UserDBConnector
# quantara/web_app/db/crud/user.py:17
class UserDBConnector(DBConnector): # inherits DBConnector
# quantara/web_app/db/crud/base.py:19
class DBConnector:
def __init__(self, db_url: str = SQLALCHEMY_DATABASE_URL):
self.engine = create_engine(db_url) # Creates its own engine!database.py:24 already creates the engine — then DBConnector creates another one.
Impact
Medium — maintainability and testing difficulty. Deep inheritance makes testing hard (cannot easily mock intermediate layers). Changes to DBConnector ripple through all descendants. Adding new operations requires understanding the full chain. Two engine instances create confusion about which pool is used.
Proposed Solution
Refactor to composition: PositionDBConnector takes a DBConnector instance via constructor injection. Same for UserDBConnector. Each class depends on DBConnector directly rather than inheriting — or better, use the FastAPI get_database() dependency for session management.
Acceptance Criteria
File Map
quantara/web_app/db/crud/position.py — refactor to compositionquantara/web_app/db/crud/user.py — refactor to compositionquantara/web_app/db/crud/base.py — simplify DBConnectorquantara/web_app/db/database.py — may need session factory exportquantara/web_app/tests/db/ — update all DB tests
Testing Strategy
- Unit: Test each refactored class in isolation with mocked DBConnector
- Integration: Run full test suite — verify all database operations still work
Security Considerations
No security impact. Purely structural refactoring.
Definition of Done
Labels: refactoring
Priority: Medium
Difficulty: Advanced
Estimated Effort: 3d
Problem Statement
PositionDBConnector → UserDBConnector → DBConnectorforms a three-level deep inheritance chain. This is a fragile "diamond" pattern:PositionDBConnectorinherits fromUserDBConnectorwhich inherits fromDBConnector, but bothPositionDBConnectorandDBConnectorcreate their own engine instances.Evidence
database.py:24already creates the engine — thenDBConnectorcreates another one.Impact
Medium — maintainability and testing difficulty. Deep inheritance makes testing hard (cannot easily mock intermediate layers). Changes to
DBConnectorripple through all descendants. Adding new operations requires understanding the full chain. Two engine instances create confusion about which pool is used.Proposed Solution
Refactor to composition:
PositionDBConnectortakes aDBConnectorinstance via constructor injection. Same forUserDBConnector. Each class depends onDBConnectordirectly rather than inheriting — or better, use the FastAPIget_database()dependency for session management.Acceptance Criteria
PositionDBConnectorno longer inherits fromUserDBConnectorUserDBConnectorno longer inherits fromDBConnectorDBConnector(or session) via constructordatabase.py)File Map
quantara/web_app/db/crud/position.py— refactor to compositionquantara/web_app/db/crud/user.py— refactor to compositionquantara/web_app/db/crud/base.py— simplify DBConnectorquantara/web_app/db/database.py— may need session factory exportquantara/web_app/tests/db/— update all DB testsTesting Strategy
Security Considerations
No security impact. Purely structural refactoring.
Definition of Done
Labels: refactoring
Priority: Medium
Difficulty: Advanced
Estimated Effort: 3d