arne/msg
0
0
Fork 0
Code Issues 5 Pull requests Projects Releases Packages Wiki Activity

store: paginate Inbox / Outbox / MessagesWithPeer #4

New issue
Open
opened 2026-05-07 09:53:10 +02:00 by arne · 0 comments
arne commented 2026-05-07 09:53:10 +02:00
Owner
Copy link

Problem

store.SQLite.Inbox() and store.SQLite.Outbox() return all rows with no LIMIT. MessagesWithPeer is similarly unbounded. This is fine while the database is small but scales linearly with retention; a daemon running for a year on a busy URL will eventually load O(N) rows into the TUI's memory each refresh tick.

Proposal

  1. Default LIMIT (e.g. 200) on every read query.
  2. before_id / after_id paging parameters on the read methods, with the TUI requesting newer pages on scroll.
  3. For the unified-thread view, paginate by message rowid descending (newest first).

Schema-side this needs no change — the existing messages.id primary key is the natural cursor.

Acceptance criteria

  • All read methods accept (limit int, beforeID int64) or equivalent.
  • TUI requests one page initially and loads older messages on demand (PgUp / [?).
  • No method materializes more than limit rows.
  • Existing tests pass with the new signatures.

Context

Surfaced in the v1.0.0 self-review. Defer until the daemon has accumulated enough history that it actually matters; the schema is already paging-friendly so this is a pure read-side change.

## Problem `store.SQLite.Inbox()` and `store.SQLite.Outbox()` return *all* rows with no LIMIT. `MessagesWithPeer` is similarly unbounded. This is fine while the database is small but scales linearly with retention; a daemon running for a year on a busy URL will eventually load O(N) rows into the TUI's memory each refresh tick. ## Proposal 1. Default LIMIT (e.g. 200) on every read query. 2. `before_id` / `after_id` paging parameters on the read methods, with the TUI requesting newer pages on scroll. 3. For the unified-thread view, paginate by message rowid descending (newest first). Schema-side this needs no change — the existing `messages.id` primary key is the natural cursor. ## Acceptance criteria - [ ] All read methods accept `(limit int, beforeID int64)` or equivalent. - [ ] TUI requests one page initially and loads older messages on demand (PgUp / `[`?). - [ ] No method materializes more than `limit` rows. - [ ] Existing tests pass with the new signatures. ## Context Surfaced in the v1.0.0 self-review. Defer until the daemon has accumulated enough history that it actually matters; the schema is already paging-friendly so this is a pure read-side change.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
No results found.
Labels
Clear labels   
needs-triage
PRD or issue awaiting triage

No labels
needs-triage
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
arne/msg#4
No description provided.