tomdebone
c586fd39c9
AT Protocol PDS + AppView + Tauri Desktop Client, 160-char post limit. - PDS (Rust + axum + sqlx) - Auth: createAccount, createSession, refreshSession - Records: createRecord, deleteRecord (race-safe via SELECT FOR UPDATE) - Feed: feed.like.create, feed.repost.create - Sync: getRepo, getBlocks, getLatestCommit, getRecord (with MST proof), listRepos - Identity: resolveHandle - MST: spec-conformant (at-mst crate, 27 tests) - Repo: signed commits, TID counter (monotonic, 4096 wrap safe) - AppView (Rust + axum + sqlx) - Jetstream consumer (WebSocket, exponential backoff, 38k+ events indexed) - REST API: timeline/home (graph-aware), profile, search, post (with thread hydration) - Handle-sync worker (did:plc + did:web) - JSONB embed storage + thread columns (migration 0003) - Like/repost counter cache (migration 0004) - Tauri 2 + Svelte 5 Desktop Client - System tray (Show/Compose/Quit menu) - OS notifications (tauri-plugin-notification) - Auto-update (tauri-plugin-updater, placeholder endpoint) - Window-state (tauri-plugin-window-state) - 160-char compose with live counter - Image/Link embed rendering - LocalStorage-persisted like state - Timeline with poll (prepend new posts) - Custom TitleBar (transparent, no decorations) - Orange/IBM Plex Mono maarcade design Tests: 231 Rust + 9 vitest = 240 passed.
45 lines
2.0 KiB
SQL
45 lines
2.0 KiB
SQL
-- AppView migration 0004: like/repost counter cache + uniqueness
|
|
--
|
|
-- Phase 5b review identified two issues:
|
|
-- H3 — Users could spam `feed.like.create` against the same post because
|
|
-- the `likes` PK is just `uri` (the like's own rkey). Adding a
|
|
-- partial unique index lets us short-circuit "already liked" at the
|
|
-- DB layer instead of relying on caller discipline.
|
|
-- H6 — `SELECT COUNT(*) FROM likes WHERE post_uri = $1` on every post fetch
|
|
-- doesn't scale. We add a denormalized counter on `posts` that's
|
|
-- kept consistent by the AppView's own ingest path. Jetstream-driven
|
|
-- upserts touch this too. The PDS path goes through ingest-commit
|
|
-- which routes through the same code.
|
|
--
|
|
-- Idempotent: dedup likes/reposts first (real-world Jetstream replays can
|
|
-- leave duplicates). Keep only the oldest row per (did, post_uri).
|
|
|
|
-- dedup likes: keep only the lowest uri per (did, post_uri)
|
|
DELETE FROM likes a USING likes b
|
|
WHERE a.did = b.did
|
|
AND a.post_uri = b.post_uri
|
|
AND a.uri > b.uri;
|
|
|
|
-- dedup reposts: same approach
|
|
DELETE FROM reposts a USING reposts b
|
|
WHERE a.did = b.did
|
|
AND a.post_uri = b.post_uri
|
|
AND a.uri > b.uri;
|
|
|
|
CREATE UNIQUE INDEX IF NOT EXISTS likes_did_post_uri_idx
|
|
ON likes (did, post_uri);
|
|
|
|
CREATE UNIQUE INDEX IF NOT EXISTS reposts_did_post_uri_idx
|
|
ON reposts (did, post_uri);
|
|
|
|
ALTER TABLE posts ADD COLUMN IF NOT EXISTS like_count BIGINT NOT NULL DEFAULT 0;
|
|
ALTER TABLE posts ADD COLUMN IF NOT EXISTS repost_count BIGINT NOT NULL DEFAULT 0;
|
|
|
|
-- Backfill: compute current counts from the now-deduped rows so the
|
|
-- column matches reality on upgrade. Wrapped in a single statement so
|
|
-- it's fast even on 100k+ rows.
|
|
UPDATE posts p
|
|
SET like_count = COALESCE((SELECT COUNT(*) FROM likes WHERE post_uri = p.uri), 0),
|
|
repost_count = COALESCE((SELECT COUNT(*) FROM reposts WHERE post_uri = p.uri), 0);
|
|
|
|
CREATE INDEX IF NOT EXISTS posts_count_idx ON posts (like_count DESC, repost_count DESC); |