Persist transcripts in SQLite #38

Open
mike wants to merge 1 commit from split-5 into split-4
Owner

Replace the in-memory store with the SQLite store so transcripts
survive restarts. The initial migration creates three tables:
transcripts holds stable metadata (slug, title, meeting date, YouTube
video ID, creation time), speakers holds each transcript's speaker IDs
and names, and transcripts_contents holds append-only revisions of the
segment array as JSON with a last_modified timestamp.

Import writes the metadata, speakers, and first revision in one
transaction and returns ErrTranscriptExists when the slug is taken.
Segment edits locate the segment with json_each, build the new array
with json_set, and insert it as a new revision inside a serializable
transaction, so earlier revisions are never modified. The revision
with the greatest ID is current, which avoids depending on wall-clock
ordering. Timestamps use RFC3339Nano so reads round-trip exactly.

Transcript gains Created and LastModified, which the store populates
from the metadata row and the current revision. test_sqlite exposes a
direct database connection and a controllable clock so store tests
can verify revision counts and stored JSON. Handler tests now run
against SQLite, and the memory store package is removed. DESIGN.md
documents the storage model.

Validation: dev-scripts/build-all-flake-targets

Replace the in-memory store with the SQLite store so transcripts survive restarts. The initial migration creates three tables: transcripts holds stable metadata (slug, title, meeting date, YouTube video ID, creation time), speakers holds each transcript's speaker IDs and names, and transcripts_contents holds append-only revisions of the segment array as JSON with a last_modified timestamp. Import writes the metadata, speakers, and first revision in one transaction and returns ErrTranscriptExists when the slug is taken. Segment edits locate the segment with json_each, build the new array with json_set, and insert it as a new revision inside a serializable transaction, so earlier revisions are never modified. The revision with the greatest ID is current, which avoids depending on wall-clock ordering. Timestamps use RFC3339Nano so reads round-trip exactly. Transcript gains Created and LastModified, which the store populates from the metadata row and the current revision. test_sqlite exposes a direct database connection and a controllable clock so store tests can verify revision counts and stored JSON. Handler tests now run against SQLite, and the memory store package is removed. DESIGN.md documents the storage model. Validation: dev-scripts/build-all-flake-targets
Persist transcripts in SQLite
All checks were successful
ci/crow/pr/build Pipeline was successful
4430edffae
Replace the in-memory store with the SQLite store so transcripts
survive restarts. The initial migration creates three tables:
transcripts holds stable metadata (slug, title, meeting date, YouTube
video ID, creation time), speakers holds each transcript's speaker IDs
and names, and transcripts_contents holds append-only revisions of the
segment array as JSON with a last_modified timestamp.

Import writes the metadata, speakers, and first revision in one
transaction and returns ErrTranscriptExists when the slug is taken.
Segment edits locate the segment with json_each, build the new array
with json_set, and insert it as a new revision inside a serializable
transaction, so earlier revisions are never modified. The revision
with the greatest ID is current, which avoids depending on wall-clock
ordering. Timestamps use RFC3339Nano so reads round-trip exactly.

Transcript gains Created and LastModified, which the store populates
from the metadata row and the current revision. test_sqlite exposes a
direct database connection and a controllable clock so store tests
can verify revision counts and stored JSON. Handler tests now run
against SQLite, and the memory store package is removed. DESIGN.md
documents the storage model.

Validation: dev-scripts/build-all-flake-targets
All checks were successful
ci/crow/pr/build Pipeline was successful
This pull request can be merged automatically.
You are not authorized to merge this pull request.
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u origin split-5:split-5
git switch split-5

Merge

Merge the changes and update on Forgejo.

Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.

git switch split-4
git merge --no-ff split-5
git switch split-5
git rebase split-4
git switch split-4
git merge --ff-only split-5
git switch split-5
git rebase split-4
git switch split-4
git merge --no-ff split-5
git switch split-4
git merge --squash split-5
git switch split-4
git merge --ff-only split-5
git switch split-4
git merge split-5
git push origin split-4
Sign in to join this conversation.
No reviewers
No labels
No milestone
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
oe/transcripts!38
No description provided.