Picking a date from before the oldest log entry rendered nothing at all.
history() truncates its window at min(date) — correct, there is no history
before the first entry to be missing — and loadDays widened the window by
inflating the day count, which that truncation then undid. No row for the
selected day meant no board to log it in, so the one thing you would want an
old empty day for was the one thing you could not do. The same happened past
maxHistoryDays, reachable straight from the date picker.
history() now takes the selected day as an explicit floor instead of the
caller guessing a day count, and date() clamps the past at maxHistoryDays the
way it already clamped the future — the list runs unbroken from today down to
the selection, so a picker set to 1994 would otherwise ask for eleven thousand
rows.
While in there:
- entriesBetween replaces the day-at-a-time entryFor loop. Two queries for
the whole window rather than two per day; the widest window a URL can ask
for was 3,600 round trips through a pool of exactly one connection.
- softDeleteMain and updateMain filter on special = 0. The catalog never
lists Tähteet, but a stale tab or a hand-made POST could still have removed
the row migration 0002 guarantees.
- WriteTimeout and IdleTimeout on the server. With one database connection, a
reader stalling on a long history response blocks everything behind it.
Two tests, both of which fail on the old code: a day 100 back with only today
logged, and sides landing on their own day now that they arrive in one query.
Esa Kataja
0f0f04240a