No description

malice 3c00b69a55 navi-places: place_cache TTL (default 30 days) (#33) ... When PR #30 (wikivoyage name-based discovery) landed, every place cached before the fix kept returning stale (no-wikivoyage) responses until a manual TRUNCATE of place_cache. A TTL makes enrichment changes propagate automatically. - place_cache.py: cache_get now treats a hit older than the TTL as a miss, so the caller refetches + re-enriches and cache_put overwrites the row (no delete on read). TTL is NAVI_PLACE_CACHE_TTL_DAYS (default 30), via _ttl_seconds(). Entries with unknown age (cached_at 0/NULL, e.g. legacy rows) are treated as expired. - No column migration needed: the schema already has cached_at INTEGER NOT NULL and cache_put already writes now(). Added an idempotent guard in get_conn anyway (PRAGMA table_info check -> ALTER TABLE ADD COLUMN cached_at INTEGER DEFAULT 0) so a hypothetical legacy on-disk DB predating the column self-heals; on the live DB and fresh DBs it is a no-op since CREATE TABLE already includes cached_at. Tests (test_place.py): within-TTL hit served from cache (no refetch); past-TTL hit refetches + refreshes cached_at; NAVI_PLACE_CACHE_TTL_DAYS=1 override expires a 2-day-old entry. Full navi-places suite: 21 passed. Co-authored-by: Matt <mj@k7zvx.com> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>		2026-05-26 16:53:25 -06:00
backend	navi-places: place_cache TTL (default 30 days) (#33)	2026-05-26 16:53:25 -06:00
frontend	Fix wiki/wikidata URL builders (Bugs 1-3 from 2026-05-24 handoff) (#28)	2026-05-26 00:04:57 -06:00