Refactor db.Store into per-domain interfaces
- Dominant language
- Go
- Stars
- 9
- Forks
- 10
- Avg merge
- 16h 55m
- Merged PRs (30d)
- 6
Description
## Classification
Task (refactor)
## Problem
`db.Store` is 45 methods across roughly nine domains with a single
implementation (`*SQLStore`); web-bff holds the concrete type and calls
`.DB()` around the interface in four places; three CLI tools write with raw
GORM instead of going through the Store.
## Direction
Carve out per-domain interfaces — `ProjectStore`, `MaintainerStore`,
`IdentityObservationStore`, `AuditStore`, `RemoteTeamStore`,
`ServiceInvitationStore`, etc. — all implemented by `SQLStore`, with each
consumer depending only on the slice it needs. `dotproject.AutoAddStore`
already proves this pattern works in this codebase.
## Motivating bug (found in PR #157 UAT)
`AdoptMaintainerIdentityObservations` re-parents orphaned observation rows
onto a newly created maintainer via a plain GORM update, which auto-touches
`updated_at`. That counterfeits freshness on rows that were never
re-observed. This was invisible in review because two methods with very
different freshness guarantees sat adjacent in one flat interface — a
symptom of the interface being too broad to reason about locally.
## Relationships
- Per an internal design note, this split is intended to be implemented as
part of a larger, not-yet-filed "maintainer observation history" redesign.
This issue may end up folded into / closed by that larger issue once it is
filed — filing it now so the scope and motivating bug aren't lost.
- Related to #124 (modularize `lfxIdentityResolver` so multiple components
depend on one implementation) — same underlying problem (one shared
capability, multiple ad hoc consumers), different interface.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reading the db.Store and *SQLStore definitions, then compare the existing dotproject.AutoAddStore pattern with the web-bff consumers and the three CLI tools using raw GORM. Map the methods into the proposed per-domain interfaces and identify the maintainer observation history redesign dependency. Done means SQLStore implements the interfaces and consumers use only the slices they need, without the motivating freshness bug.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- backend, backend-api-design, databases
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100