- Shipped
- September 17, 2026 at 12:59 AM UTC
- Author
- Kamo
- Commit
- 2240cdd
Two tables behind the view count kamo-marketing now shows at the foot of every page, written by KBService's /internal/page-views endpoints. KbArticleView (KB_ARTICLE_VIEWS) counts a knowledge-base article's views on the ARTICLE, keyed by its uid, so the count is part of the article and follows it when it is renamed or moved in /kb. It is a table of its own rather than a column on KB_ARTICLES: the article row is saved whole by JPA, so a counter on it would be read when an editor opened the article and written back when they saved, discarding every view in between. The foreign key cascades in the database, because KbArticle does not map this row and a Hibernate delete of an article would otherwise fail on it. MarketingPageView (MARKETING_PAGE_VIEWS) counts every other page on its path below the locale prefix, so /en/pricing and /fr/pricing share one count. Both keep SEED_COUNT, the starting figure a row is created with, apart from VIEW_COUNT, the views actually counted; the page shows their sum, and real traffic stays readable from the table. The repositories expose only the three statements a view needs: a native upsert that counts, one that seeds without counting, and the total, read after the write in the same transaction. No save(): a counter loaded, incremented and saved back loses concurrent views. Checked offline: a session factory builds over all eleven KB entities plus these on Hibernate 6.2.13 (KBService, and the other Boot 3.1 services) and 6.5.3 (Boot 3.3), and the schema script it writes matches the DDL applied by hand, including ON DELETE CASCADE. ddl-auto is none everywhere but the initializer, so no other service touches the tables.