Sync docs/02-interfaces.md with the actual GetRecurringExpenses signature #14

New Issue

2026-06-28T09:42:35Z

admin commented

2026-06-28 09:42:35 +00:00

Context

docs/02-interfaces.md:107 documents:

class GetRecurringExpenses(dao: RecurringExpenseDao, categoryDao: CategoryDao) {

But PR #10 (feat/3-implement-recurring-interactors) ships it as single-DAO:

class GetRecurringExpenses(
    private val recurringDao: RecurringExpenseDao,
)

The simplification is correct: RecurringExpenseDao.subscribeAll() uses @Relation to join the category in a single query (app/src/main/java/dev/achmad/ledgerr/data/local/dao/RecurringExpenseDao.kt:27-29), so a second CategoryDao would be redundant. awaitOne(id) only needs the recurring entity, not the category, so the simpler constructor is enough.

GetExpenses in PR #2 keeps its two-DAO shape because ExpenseDao.getById and search do not use @Relation — so the asymmetry between the two interactors is justified by the DAO design, not a doc bug.

The original issue #3 step 3 also told the implementer to register GetRecurringExpenses(get(), get()); the implementer correctly registered it with one arg, but the spec was stale.

What to do

Update docs/02-interfaces.md:107 to the single-DAO form:

class GetRecurringExpenses(dao: RecurringExpenseDao) {
    fun subscribeAll(): Flow<List<RecurringExpenseWithCategory>>
    suspend fun awaitOne(id: Long): RecurringExpense?
}

(Optional) Add a one-line note in docs/02-interfaces.md explaining why GetRecurringExpenses is one-DAO while GetExpenses is two-DAO — the difference is whether the DAO query uses @Relation.

Acceptance

docs/02-interfaces.md matches the actual GetRecurringExpenses constructor
(Optional) the asymmetry with GetExpenses is documented

Implementation rule

Per AGENTS.md — do not start implementation without explicit user sign-off on this issue. When working, check for related issues in the remote repo first.

## Context `docs/02-interfaces.md:107` documents: ```kotlin class GetRecurringExpenses(dao: RecurringExpenseDao, categoryDao: CategoryDao) { ``` But PR #10 (`feat/3-implement-recurring-interactors`) ships it as single-DAO: ```kotlin class GetRecurringExpenses( private val recurringDao: RecurringExpenseDao, ) ``` The simplification is correct: `RecurringExpenseDao.subscribeAll()` uses `@Relation` to join the category in a single query (`app/src/main/java/dev/achmad/ledgerr/data/local/dao/RecurringExpenseDao.kt:27-29`), so a second `CategoryDao` would be redundant. `awaitOne(id)` only needs the recurring entity, not the category, so the simpler constructor is enough. `GetExpenses` in PR #2 keeps its two-DAO shape because `ExpenseDao.getById` and `search` do not use `@Relation` — so the asymmetry between the two interactors is justified by the DAO design, not a doc bug. The original issue #3 step 3 also told the implementer to register `GetRecurringExpenses(get(), get())`; the implementer correctly registered it with one arg, but the spec was stale. ## What to do 1. Update `docs/02-interfaces.md:107` to the single-DAO form: ```kotlin class GetRecurringExpenses(dao: RecurringExpenseDao) { fun subscribeAll(): Flow<List<RecurringExpenseWithCategory>> suspend fun awaitOne(id: Long): RecurringExpense? } ``` 2. (Optional) Add a one-line note in `docs/02-interfaces.md` explaining *why* `GetRecurringExpenses` is one-DAO while `GetExpenses` is two-DAO — the difference is whether the DAO query uses `@Relation`. ## Acceptance - [ ] `docs/02-interfaces.md` matches the actual `GetRecurringExpenses` constructor - [ ] (Optional) the asymmetry with `GetExpenses` is documented ## Implementation rule Per `AGENTS.md` — do not start implementation without explicit user sign-off on this issue. When working, check for related issues in the remote repo first.

admin commented

2026-06-28 09:44:41 +00:00

Closing — addressed as a review comment on PR #10 (#10) instead of a separate issue.

Closing — addressed as a review comment on PR #10 (https://git.achmad.dev/admin/ledgerr/pulls/10) instead of a separate issue.

admin closed this issue

2026-06-28 09:44:47 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: admin/ledgerr#14