4 Commits

Include renames

Author	SHA1	Message	Date
sneak	a6eba6045e	Declare only the tables and columns pixa writes and reads (closes #310) ... Removes output_content and request_cache, which nothing writes, and every column that was written but never read: the host, path, query and fetched_at of source_content, the content_type and created_at of variant_content, and the status_code, error_message and fetched_at of negative_cache. StoreVariant no longer takes a content type and StoreNegative no longer takes a status code or message, so extractStatusCode and the status constants, which only fed status_code, are gone. Reconciliation adopts a variant file without opening it, as its row no longer records a content type. Tests that set or checked a removed column follow. Model: opus-5-5	2026-10-21 16:22:28 +00:00
clawbot	a19cca2f34	Store a source the way a variant is stored, one row and one file per source URL (closes #308) ... A source is now one source_content row and one file named by its SourceKey, the SHA-256 of its host, path and query, made as the variant key is. A store writes the file, then upserts the row, and removes the file when the row cannot be written; an eviction deletes the row, then the file, with no lock. source_metadata, the JSON files under cache/metadata/, MetadataStorage, the content lock, the eviction transaction and its test hook are gone, as is the reconciliation pass that dropped a source row whose file is missing. Two source URLs serving the same bytes store them twice. Model: opus-5-5	2026-10-21 16:31:33 +02:00
clawbot	5058fd532b	Queue SQLite writes on one connection so none fails as locked (closes #223) ... internal/database now opens the database with one connection. pixa's own reads and writes run on it one at a time instead of competing for SQLite's lock, where a write that kept losing could wait past the five-second busy timeout and fail with "database is locked". The busy timeout stays, for another program writing to the same file. With one connection, a query run while rows or a transaction are still open would wait forever. No code in internal/database or internal/imgcache does that; the comment on DB() tells callers. README.md says pixa uses one connection and that requests wait while eviction runs one of its queries. Model: opus-5-5	2026-10-08 04:50:31 +02:00
clawbot	625fd42ace	Wait on a busy SQLite database and turn on WAL mode (closes #198) ... Requests and the eviction pass write on separate connections, and with no busy timeout a write that met another one failed at once with "database is locked" and was lost. internal/database now adds _pragma=busy_timeout(5000) to every db_url, the default or one the operator sets, so such a write waits up to five seconds. The default db_url's _journal_mode=WAL is not a parameter the driver reads, so it is now _pragma=journal_mode(WAL). README.md and config.example.yml say what pixa adds to db_url. Model: opus-5-5	2026-10-04 20:58:37 +02:00