Repository navigation
Speed up the feasts page and story checks - #284
Merged
Merged
Conversation
year_of_feasts built a liturgical Day for all 365 dates, two to five queries each and mostly for saints the page never shows. It now fetches the rows that can make a date a feast or a fasting day in one query, merges each date's rows with _merge_tradition_days as Day does, and builds a whole Day only for the twenty or so feasts, for their names. The fast-level rules that fasting.apply used to set inline (fast-free days and the Apostles' fast) move into fasting.fast_level so both paths share them, and Day's civil-to-church date conversion becomes church_date for the same reason. A year now takes 15-23ms and 37-73 queries, down from 214-388ms and 730-1628. The old and new code agree on every year from 1990 to 2110 on both calendars and traditions. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
year_of_feasts walked all 365 dates and built a full Day for each feast just for its name. It now works out the civil dates its rows fall on -- fixed rows from their church date, Paschal and floating rows from each of the two Paschal years a civil year spans, plus the Apostles' Fast -- and names each feast from the merged rows it already has. A year is now 3-4ms and one query. It still matches the old Day-per-date code on every year from 1990 to 2110. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
_has_story stripped every story's HTML on every Day to catch markup-only stories like '<p></p>', a fifth of building a month calendar. #172 cleared the nine there were, so it now checks for text directly, and a test fails if the data ever brings one back. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This was referenced Nov 6, 2026
Merged
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two speedups: the feasts page no longer builds a liturgical
Dayat all, and everyDaygets cheaper because it no longer strips each story's HTML.Feasts page
The page used to build a
Dayfor all 365 dates. Each one costs two to five queries, mostly for saints the page never shows. In production a year took about 1 second (New Relic median 961ms).What changed.
Dayrows that can make a date a feast or put it in a fasting season: feast level 6 and up, fast level 2 and up, fast-free days, and every tradition row (an override can lower a common row's level).Day._collect_commemorationsdoes and merged with the same_merge_tradition_days. Feast names come from the merged rows, so noDayis built.Shared rules instead of copies.
fasting.fast_levelnow holds the two rulesfasting.applyused to set inline: fast-free days and the Apostles' fast. Both paths call it.church_dateinday.pyisDay's civil-to-church date conversion, pulled out for the same reason.Speed (local, 2027):
Stories
_has_storystripped the HTML from every story on everyDay. It did that to catch markup-only stories like<p></p>, and it took about a fifth of building a month calendar. #172 cleared the nine such stories from the data, and none are left among the 892._has_storynow just checks for text, and a new test fails if the data ever brings a markup-only story back.A month calendar now renders in 15.8ms, down from 19.4ms (local median); the readings page and the day API save the same per
Day.Testing
🤖 Generated with Claude Code